The risk of implementing new, unproven technology looms large in most content strategy projects. A bad technology decision can derail or destroy an otherwise compelling project. However, it is our experience that poor technology choices are rarely the cause of a failed project. Bad project management is a much more likely culprit.
- Bad fit. It is critically important to choose tools and technologies that solve your organization’s problems. The fact that a particular system offers much better support for Feature X is interesting only if you actually need Feature X. A system that works miracles for another organization may not be appropriate for your organization.
- Deficient products. Some products do not deliver what they promise, or a feature is implemented in a way that does not solve the problem you need to solve. You can avoid this trap with pilot projects and other field testing. Pay attention to industry scuttlebutt—which vendors have good reputations? Which vendors are heavily criticized? Are the criticisms relevant to your requirements?
- Customer support issues. You think it is a missing feature. The vendor may insist it is a support or custom configuration problem. How does the vendor handle customer support? Are current customers generally pleased with the vendor? What happens when (not if) you uncover a bug in the product? Good customer support will mitigate the inevitable bumps in the road; bad customer support will magnify them.
- Scalability. Is the technology designed to handle the scope of content you need? What if you are wrong about the scope and you need to scale up significantly? For example, what if an unexpected acquisition triples the amount of content you are managing? Can the product handle additional content, languages, outputs, authors, reviewers, and so on? Will the cost of the product increase?
As you define your content strategy, you can identify requirements for your technology layer. A good set of requirements will help you narrow your choice of tools to something manageable. Requirements should be measurable and be closely related to your strategy and therefore your business goals. For example, assume one of your goals is to control localization costs by reducing the amount of manual formatting done in production. You need a workflow that provides for efficient exchange with localization service providers, automates formatting, and supports all of the languages you need or expect to need.
Building requirements that tie back to your strategy will help you if you decide to change the toolset.
Tenacious ties to tools
Many content creators have strong opinions about the tools they use. Their ferocious (rabid?) loyalty presents an implementation challenge.
A high level of proficiency in a specific tool fosters a sense of achievement and security in team members. But a strong attachment to a tool can cause “tool myopia.” Symptoms of this affliction include:
- Automatically rejecting other tools
- Using a current tool’s capabilities as the benchmark for excellent technical content
- Defining new process requirements based on the current tool’s capabilities
- Focusing on short-term productivity losses associated with new tools instead of considering the long-term gains
- Seeing new requirements through the lens of whether the current tool can accomplish them efficiently
The straightforward (but admittedly painful) cure for this myopia is building requirements. Strategic thinking about content cannot happen when early discussions are framed as “Tool X can do this, and Tool Y can do that.” Focus first on the strategy; the tools come later.
For example, ask teams to evaluate what outputs (web pages, printed data sheets, PDF guides, online knowledge bases, and so on) content consumers need. Build wireframes and prototypes for these outputs, followed by more detailed specifications. How closely do the new outputs resemble existing outputs? The bigger the difference, the more likely that you may need new tools. Start the conversation about tools only after you thoroughly understand the requirements.
Include your current tools in the assessment to see how well they meet the requirements. It is possible that your existing toolset will support your new content requirements.
During consideration of process changes, content creators (including technical communicators, marketing staff, and instructional designers) often attempt to bias requirements analysis—usually, toward the incumbent toolset. Instead of an honest evaluation of the process of creating and distributing information, content creators jump on their favorite tools and start jockeying for position. By focusing on familiar tools, these employees make the creation and distribution of content about themselves and not what is best for the organization. A narrow focus on avoiding change makes the content creators less credible in their organization and diminishes the potential business value of content.
It can be difficult to get employees from multiple departments to focus on how technical content serves the entire organization, much less do that and steer conversations away from tools. Instead of managing these challenges on your own, consider hiring an experienced consultant to act as your requirements wrangler.1 The consultant can:
- Gather feedback from end users and departments that consume technical content. External and internal content consumers are generally more honest when talking to a third party and not the content creators. Candid assessments of the current technical content are critical for developing requirements that maintain the positive qualities of existing content and improve upon its deficiencies.
- Refocus conversations among content creators when discussions become tool-centric. If content creators are displeased about the lack of tool talk, let the consultant bear the brunt of that unhappiness—better the consultant than you. A skilled consultant is accustomed to such reactions and should be able to diffuse any tension.
- Offer guidance and suggestions on long-term goals for content. As a manager, you may oversee the revamping of technical content just once in your professional lifetime. Consultants, however, often work on multiple content projects in a single year (sometimes concurrently). The expertise consultants gain from their past projects can be an invaluable asset to your efforts—and help you develop requirements for improvements you wouldn’t have considered on your own.
- Compile a report to codify requirements. Designating the report as a deliverable from the consultant gives you a specific milestone for payment (which will make the accounting department happy), and it can provide you with a checklist for evaluating tools during the implementation phase.
To break up the costs associated with hiring a consultant, set up requirements development and implementation as separate projects. Many companies develop requirements in one quarter (or fiscal year) and begin implementation in another.
The continuity of having the same consultant work on both requirements and implementation is very beneficial with the right consultant. Having those two phases as separate projects offers you an escape hatch if your relationship with a consultant does not work out during requirements gathering.
Getting involved with your IT department
In the excitement of establishing a new content strategy, it’s easy to overlook management and maintenance requirements for the required tools and infrastructure. Your information technology department, however, is painfully aware of these issues, and should be involved in the decision process very early on. IT can help you minimize (or eliminate) many technology-related risks.
Put aside the typical us-versus-them mentality. “Really? Is the IT department going to lock that down, too?” If you are going to put enterprise-level tools in place (as opposed to desktop applications), you are going to need help from IT. Early IT involvement is particularly critical if you are installing a content management system. To implement a new CMS, you will need information that goes way beyond the requirements of the teams who will use these new systems:
- How much time will it take to maintain the system (database maintenance, backups, and so on)?
- As more users and content are added to the system, how does maintenance time increase?
- Should the CMS reside on a physical or virtual server? How well will that server scale as users and content are added?
- Can the current Internet connection and network handle the CMS (particularly when multiple sites are involved)? Does the company need a bigger pipe to accommodate CMS activity?
- How will user accounts be added and removed from the system? Does the CMS integrate with the single sign-on solution your company already has in place?
- Will there be in-depth training provided to the IT personnel on the CMS? What about follow-on support?
- What is the process for installing new releases, and what kind of time do they generally require?
- Is there a hosted solution that eliminates maintenance tasks if the IT staff doesn’t have the resources to manage another system?
Building a strong relationship with IT will be especially helpful when it is time to have The Talk. IT groups generally want to consolidate technology and to avoid proliferation of systems (both are very sensible goals), so they prefer to use existing technologies that could support your efforts. Sooner or later, they will ask, “What about SharePoint?”
If you have a detailed requirements document, you can work with IT to determine whether SharePoint meets the requirements. (Hint: Probably not. SharePoint is a document management system, not a component content management system.) Most technical content strategies rely on reuse at the paragraph and topic level, which is poorly supported by SharePoint.
Content creators and IT must work together to get the answers to critical technology questions—whether they like it or not! The content creators need to understand how their new tools affect IT, and the IT group must learn about how its efforts support specific content requirements.