Change Management: Remove the hand-cuffs that are getting in the way of your digital transformation

Ixxus has an amazing track record of successfully implementing and deploying technology solutions that enable digital transformation. But, they do just that… enable. Just because a system has the capabilities described in the Imbue whitepaper, such as the centralized storage and accessibility, creation of content that’s highly enriched with metadata, mix and match asset reuse in multiple products, collaborative authoring and review, etc., doesn’t mean that an organization will evolve their processes to leverage these features or implement them in an efficient or effective manner. Yes, digital transformation requires investment in technology, but it’s ultimately the people and processes that will implement and sustain the changes.

This makes common sense, right? But, you’d be amazed at what I sometimes see when I visit organizations following their roll-out of a feature-rich publishing platform that can support a full-on, major digital transformation.

I’ve seen organizations that will embrace changes at first, but then slowly revert to old habits. For example, they rigorously capture metadata during content migration and maybe for a few months beyond that, and then it slips back to its prior state of being inconsistently captured (and we know that poor quality metadata is just as bad or worse than no metadata, as we explained in this blog post). When this happens, how will this impact the business goal of improving consumer discoverability and the online experience that may depend on that metadata?

And I’ve seen mixed adoption within the same company. For example, some editorial teams may embrace real-time collaborative review capabilities, while other editorial teams won’t let go of their paper and red pens. When this happens, how will this impact the productivity improvement or return on technology investment goals expected by the business?

I’ve also seen very basic content management principles get blatantly ignored. For example, when a user makes an update, they replicate the asset in the repository rather than use versioning (e.g., create/upload separate assets with dates or version numbers in the title just like they did on their file system, rather than letting the publishing platform automatically track this as a single asset with multiple versions). Seems like no big deal. But, when this happens, how does this impact all the business goals that rely on agile content that has a “single source of truth,” such as increasing revenue by reusing assets to create new derivative products, or reducing the costs of updates, or delivering real-time content to consumers?

And when I observe how users are using the new platform, and I point out a capability that they didn’t show, I internally face-palm when users tell me, “I didn’t know it did that!” They may have been trained on the system, but not their new processes that will use it, so it didn’t “stick.” When that happens, these great “enabling” platform features get lost and forgotten, and the business benefits do not get realized.

Worst case, this highly sophisticated publishing platform gets used like a “fancy Dropbox” when there’s little to no change management for driving transformation to the processes and people that need to leverage it. An STM VP quoted in the Imbue whitepaper said, “Right now, we are hand-cuffed and can’t generate new products because content is not agile enough.” Many of us immediately jump to the conclusion that the technology is the hand-cuff. But, it can equally be the processes and people, as well.

So far in this blog, I’ve talked about a few “epic fails” of change management that I’ve seen, but on the positive side, I’ve also worked with a lot of organizations that have undergone huge successful digital transformations.  If these companies have implemented relatively the same capabilities in a publishing platform (in other words, let’s take technology off the table), what are these successful digital transformation companies doing that the others are not? Rather than give a generic answer that you can find in any good change management book, I thought I’d reflect on a few specific things that I’ve seen these organizations do:

  1. Leverage experts: Seek out a partner that has helped other companies through a digital transformation and can serve as a trusted advisor for you. It’s not just about guiding you through what works, it’s helping you to avoid things that don’t work. Mistakes experienced by other companies don’t have to be repeated in yours. Okay, I’m biased here, but this is a big part of what I do in Discovery engagements with my clients.
  2. Go big or go home: Be careful of thinking that small incremental changes can get you to digital transformation. Often when I work with teams to reengineer a process, the tendency is to just make adjustments to the existing process, which can provide some efficiency improvements, but they’re also more likely to revert back to the “same old, same old” over time. Successful companies at digital transformation don’t get stuck in “we’ve always done it this way” justifications. They look with fresh eyes at a new ideal process that supports the new business goals.
  3. Involve evangelists from the start: Find the users that understand the big picture and “get” how changes to technology and process will impact the business in both positive and negative ways. These evangelists will also help “sell” changes internally and can be key drivers of the transformation. They’ll also help you navigate the obstacles. The best evangelists are not always the most vocal users or the “manager favorites.” They’re the ones most respected by their peers.
  4. Seek and convert the skeptics, rather than avoiding them: Find out why the skeptics are skeptical. They might have valid concerns, and they might be the same concerns that others in the organization are thinking, but not saying. Is it a coincidence that I’ve found that the biggest skeptics at the beginning of a digital transformation initiative eventually become the best evangelists in the end?
  5. If you don’t change the simple things, then forget the big things: Make sure that users are utilizing the basics of a Content Management System (CMS), such as versioning, centralized storage, accessibility and permissions, etc. This kind of basic functionality has been around for years, but if it’s not implemented or not implemented correctly, it can get in the way of leveraging the more advanced capabilities in a publishing platform.
  6. Establish governance and measure the outcomes: Ensure that the process changes that you’ve put in place “stick” through top down governance. Otherwise, the users will revert back to what they’re most comfortable with because they’re so busy with their day-to-day responsibilities. It’s important to define (and document) how you will measure the success of a new process (e.g., random sampling of outputs), so that you make sure that the initial rollout of a new publishing platform is the benchmark, and it only gets better from there. I’ve seen some companies go as far as creating formal internal Service Level Agreements (SLAs) as “contracts” to manage and monitor their performance and quality standards for their new processes.
  7. Don’t just train the technology, train the process, too: Create custom training that blends both your new process and the functionality of the publishing platform that supports it. When organizations just focus on basic “system user training,” the users may come away thinking that these new features are “cool,” but they don’t actually internalize the training and know how to incorporate the capabilities into the new process. It’s important for users to understand the business benefits, as well as the negative impacts of deviating as part of the training. Also, I’m a big fan of classroom-led, interactive, hands-on training, as this can provide a good feedback channel for capturing improvements to the process and the platform features.
  8. Don’t stop changing: Expect that the new process (and technology) will not be perfect after it’s initially deployed. In parallel to continually adding new capabilities, be sure to conduct regular retrospectives and plan for making improvements to the process and platform features already delivered based on the experiences gained.
  9. Give a flashy big capability in the first release to get people excited: Include some “eye candy” in that first release of a new publishing platform that users will want to try out and embrace. It may not be the top priority on a capabilities roadmap, but a new and exciting feature may lessen the resistance to change. For example, I’ve often suggested that clients include a collaborative electronic review functionality in an early release of a new publishing platform. From a pure business priority perspective, it might make sense to defer this capability to a later release. However, if it draws users to use a new platform and gets them excited, then “game won.”

In short, it’s important to have the right technology solution in place that can bring business value and can support editorial efficiencies and product innovation, but it’s not a magic pill. Make sure that the processes and people will leverage and sustain the delivered capabilities enabled by that solution.

Date Published : 12th of July 2017

Renee Swank

Published by : Renee Swank

About the Author : Renee is Vice President of Discovery at Ixxus. WIth more than twenty years’ experience in business process re-engineering and the implementation of editorial, content management, and production systems for large publishers, Renee works with clients to develop and implement content and technology solutions.