Don’t let CMS implementation kill your project

I heard a great talk recently from a Gartner perspective on why many tools not in the quadrant are still great software.  Here’s the thing about Content Management System (CMS) implementation failures: we always want to blame the technology.

I think we do this because it’s the “new” thing — the unknown variable. For most people, it’s the black box that they don’t understand. Additionally, in many cases, the technology is the thing implemented by someone else, not the content team. This makes it an easy scapegoat.

However, in my experience, project failures are rarely about the technology. Far more often, failure comes from the process, the people, and their perspective on the project. We look at technology as the tricky part, and we tend to ignore all the stuff around it, even when this is the stuff that’s more likely to fail.

What’s insidious is that many project failures are hidden. They’re not spectacular failures of budget or schedule, but more subtle failures of expectations.

Your project might launch on schedule and under budget, but over time, the results may not perform as well as the organization had hoped. Small things add up, and what you positioned as the ultimate solution slowly develops cracks and disappointments. Two years down the road, you’re planning a re-launch with the baggage of leftover cynicism from the first go-round.

Here’s something you might not realize: from a functional technology perspective, the average content management system is likely more than you need. Clearly, some systems are better than others, but even a basic CMS probably does as much as you need it to or can be coaxed into it by a competent implementation team.

The trick is that a CMS needs to be supported by people and process, both during implementations and after launch, and it’s those things that struggle the most.

Here’s a list of things that we tend to ignore, along with commentary and guidance on how you might resolve them in your own project. This list is far from exhaustive, but, if nothing else, it might get you thinking about all the larger issues that you might be assuming will work themselves out.

These issues are lurking on the edges of your project, just over the horizon. You can’t see them, but they’re waiting for you.

All the CMS horsepower in the world doesn’t do any good without some roles and processes in place to make sure everyone is rowing in the same direction, including after the launch. The most minimal effort might simply be a clarification of roles: who is the project owner? The project manager? Who manages the tactical issues, who manages the strategic issues, and how do those relate — when does a tactical issue require strategic review, and how do strategic issues filter down to tactical implementations?

The idea that everyone in the organization is in love with your project might be a pipe dream. Some might be overtly hostile, but others might just not understand the challenges the project is designed to overcome. You need a plan to educate and build consensus among people who might not be direct stakeholders. Aim for organizational momentum. A background “flow” of support can sweep the project up with it, and smooth over issues that might otherwise slow it down.

This often gets checked off with a plan for a few hours of desktop sharing. What we fail to recognize is that different people learn differently, and many people will require retraining over time. One training session might be enough for half the attendees, but what of the rest? Having half of the potential editors confused is an almost guaranteed adoption failure. Training is not a Big Bang event. Consider smaller training events, with affordances for impromptu, spot follow-up when memory fails.

Migration is probably at the top of the list of items that delay launch. There tends to be an assumption that content just moves itself, or that it will map over cleanly from one CMS to another. Migration is a deeply involved process which — even with competent automation — can involve large amounts of manual labor to scrub, tune, and optimize content in the new system. Plan for the migration early — in fact, content inventory and extraction can begin even before the new website build starts. Over-budget schedule and funds to a migration.

In a CMS implementation, editors tend to get the short shrift. We concentrate more on the end consumers of the content, and assume that the out-of-the-box editorial environment will be enough. We fail to acknowledge the level of customization we can and should do to the editorial experience. Most systems allow for clear and concise field labelling, field editing, inline help and notes, stylesheet customization for rich text fields, and contextual preview optimization. Consider prototyping the editorial experience just as much as the visitor experience. Content begins with your editors, and they’re just as critical to your success as the person consuming what they produce.

This is the thing that everyone says they want, but no one wants to spend any time or budget on. The traditional view of documentation is a turgid document explaining the project from the ground up, but a more modern view might be one of curation and aggregation. Instead of writing documentation, how might you accumulate it in one place — provide a wiki, blog, or other collaborative space with links to documentation supplied by others? Supplement this with original documentation specific to your installation, but even then, perhaps expand that definition to primarily consist of non-text media — impromptu screencasts, annotated screencaps, and miscellaneous tips and tricks.

It’s clear that projects need to be quality-checked, and smart Project Managers leave time for that, but then what? It can be assumed that a least a few things aren’t going to work, and will there be time to fix them? What’s difficult about this is that there’s no way to estimate how much time will be needed, so the best idea here might be to fall back on a percentage rule: assume, perhaps, a 15% rework rate. So, for a 1,000-hour project, assume QA will reveal 150 hours of rework, and build that into the schedule. Remember, QA doesn’t exist in a bubble. There’s little logic in devoting time to QA and no time to re-work the things that it might turn up.

As project teams get larger and implementation cycles get longer, there’s a very real chance that the team which starts the project won’t be the same team that finishes it. People move in and out of roles, leave organizations, and team responsibilities get shifted. Take stock of our team before the project starts and determine the criticality of roles. If the person heading up content migration leaves halfway through the project, what does that do to the schedule and how can that role be filled? Is a critical, intensive role being staffed by a single person? Can that role be backed-up somehow? Where and how are the artefacts from that role being stored, so that they might be transitioned, if necessary? We’ve seen staff turnover decimate projects, delaying them for years.

Beyond simple internal marketing to increase awareness, you need to be prepared that people or factions in the organization might be openly hostile. There are political fiefdoms, passive aggressiveness, and people trying to justify jobs or responsibilities that are threatened by what you’re up to. To guard against this, you need to be sure your reporting lines, your project charter, and your stakeholder chain is clear to everyone. If someone at the C-level is ready to wield a big stick, your project has a better chance of running the gauntlet.

Finishing a project can be like New Year’s Eve…which means you wake up the day after without any of the energy that kept you up until midnight. At some point, you need to shake off the launch and spend some time with your users to ask critical questions about what’s working and what’s not. Keep a tickler file of project stakeholders and users. Aim to check in with someone once per week, from Day 30 to Day 90, after they’ve had a chance to settle in, but before they’ve accepted shortcomings as endemic.

We tend to consider implementation projects as solutions, not works in progress. But no implementation is static — launch day is the starting line, not the finish line. What your CMS implementation should do is instigate a never-ending cycle of tweaking, experimentation, and optimization. Consider the Sixty Percent Budget Rule which says you really only have 60% of what you think you have: if you have $10, pretend you only have $6 for launch, and save $4 for what happens after. You’ll have good ideas post-launch, and some things you do simply won’t work out how you planned and will need to change. Save budget for them.

What else should I do?

You might look at this list and think, “Well, that’s just good project management.” This is certainly true, but there’s a temptation for a project plan to immediately get bogged down in code release iterations, feature builds, and development operations. The actual development effort in implementing a CMS is intricate and can suck up most of the project manager’s time.

But understand that none of the above items is directly related to the development-level implementation of the CMS. Rather, they’re everything that surrounds and supports the CMS, the people that work with it, and the larger goal the CMS is being implemented to achieve.

Consider a target. The bullseye is the technology, not necessarily because it’s the most important thing, but because it’s the smallest and is surrounded by larger concerns. The surrounding rings might look like this:

• Governance:The humans, roles, and processes for relating to the CMS and the content goals
• Training:The specific skills for operating the CMS
• Content Operations:The migration and manipulation of actual content inside the CMS
• Marketing:The positioning of the CMS inside the larger organization

Those four items alone will have an outsized impact on the ultimate success of your project. I’ve seen sub-optimal CMS’ serve organizations extremely well because of the “outer rings” of support they were given. Conversely, I’ve seen many great CMS’ fail utterly because of organizational and management factors that nothing to do with their technical competence.

Next time you’re planning a content project or CMS implementation, consider the following exercise: assume the technology and implementation is guaranteed to be perfect in every way, and ask yourself “What else do I have to do?”

You’ll quickly find that list will be larger and more encompassing than the actual development work you’ve planned. Your bullseye will gather an expanding number of rings as you begin to acknowledge all the surrounding people and processes which need to be attended to and optimized.

The risk and uncertainty associated with the development tasks of an implementation tends to overshadow other, non-technology related issues. While counter-intuitive, ignoring technology concerns for a moment to step back and consider the broader issues might be exactly what you need to bring them into focus.