The true cost of incumbency bias
When selecting authoring and publishing tools, there is an unfortunate human instinct to cling to the familiar. This ranges from a slight preference for the tool currently in use to “You will pry this software from my cold, dead hands.”
I was talking about this with Scott Abel recently. As consultants, we bring a different perspective to the tool discussion—we have worked with lots of different systems, and we have seen our customers succeed using a variety of approaches from “excellent fit for their requirements” to, frankly, “what were they thinking??”
And that got me thinking about the incumbency bias for tools (which could be software or a process). Once a tool is in place, it is extremely difficult to displace that tool. It’s like a dam on a lake. Without the dam, the water would flow downhill and find its way to the ocean. With a dam in place, the water must reach a much higher level before it overflows and continues on its way. The incumbency bias is the dam—it prevents change.
This is not necessarily a bad thing. The benefits of the bias against change include the following:
- Productivity with known set of tools
- Avoid disruption of team workflow
- Avoiding uncertainty and stress
- Little or no training needed because team members have expertise with the toolset
In other words, calm waters.
But an organization that embarks on a content strategy assessment nearly always does so because the current workflow no longer meets the requirements of the organization. This could be due to scalability (the organization has grown, and the publishing system can’t accommodate the heavier load), new requirements (support for mobile devices), or structural changes (globalization, personalization, increased velocity). In these cases, a tendency to view possible solutions through the filter of what the incumbent toolset can do is problematic. (For another perspective on this issue, see The Design Implications of Tool Choice by Mark Baker.)
If possible, it is preferable to extend the existing toolset to support the new requirements. This is an appropriate incumbency bias. But if the existing toolset simply cannot accommodate the new requirements, then a more drastic solution may be necessary. Otherwise, you may end up with a failed content strategy.
Good topic! We deal with this sort of concern a lot as BAs and have found that it is critical to understand all of the reasons a solution is considered successful. Sometimes the reasons can be surprising. I’ve found that in general, speed/performance is the main determinate to whether a new solution is adopted. A colleague of mind wrote a series of posts on legacy conversion projects that your readers might find interesting. Check it out here: http://requirements.seilevel.com/blog/2012/06/when-replacing-legacy-applications-performance-is-key-%E2%80%93-part-4.html