»
Making the Move to Content Management – Lessons Learned For Documentation and Training Managers
Chip: Thanks for taking time out of your day to chat with me today. Can you share a little background information about yourself and your role at Astoria Software?
Craig: I’ve been helping large enterprises deploy and run a variety of business applications for the past 10 years and for the past 2.5 years have been focused on SaaS type applications. During this time, I’ve seen the nature of these deployments shift from large, highly-customized, in-house projects taking 6-18 months to very quick, flexibly configured deployments completed in a few weeks.
In my role at Astoria, I am responsible for all customer deployments which includes professional services, training, technical support and SaaS Operations. The primary focus of my organization is to ensure that our customers get up and running quickly, make the best possible use of our software and need never worry about the smooth operation of their system.
Chip: Over the years, I imagine you’ve seen your fair share of successful content management projects – as well as a few that weren’t so successful. Of those that were successful, what three things were critical to their success?
Craig: I think the most important success factor for any organization is a good, detailed understanding of the key pain points and business reasons driving the need for a CMS. This will focus all players on the reasons for the change, and it is a change for most involved, because bringing in a CMS will require abandoning some legacy processes, modifying others, and adopting new ways of working. A detailed understanding and communication of these issues can help ensure management’s support for your initiative.
The second important success factor for a CMS implementation is properly scoping and staffing the initial deployment phase. The best approach is usually a small core team that has in-depth understanding of business processes and authority to change them as required. This team should be able to coordinate, communicate, negotiate and drive these changes across all organizations affected. The core team will be responsible for configuring the features and workflow of the CMS plus adapting their company’s processes to best leverage the features of the CMS. The scope of this initial deployment should be small and focused on proper configuration and planning for larger scale rollouts. Subsequent phases can then focus communication and training of the already validated and working CMS.
The third most important success factor is to think beyond just the features of the CMS software and consider the wider aspects of Change Management that the new application is introducing. Most CMS implementations I’ve seen recently are coincident with a more pressing need to realize the benefits of DITA. This shift to structured (topic-based) authoring requires non-trivial changes in writing processes. For example, DITA’s separation of presentation (visual layout) from content may be a big change for authors and somewhat for reviewers who may be used to seeing fully rendered, full documents on each review cycle. DITA’s reuse paradigm focuses first on content-only reviews, with a final visual review done for each form of rendering chosen (web, pdf, hardcopy, etc.).
A Change Management Plan considers these wider aspects of implementing a CMS. Organizations I’ve worked with that address this up front are much quicker in adopting the system and seeing its benefits. Emma Hamer addressed some of these issues in Managing Cultural Changes Triggered By A CMS Project.
Chip: Software companies spend a lot of time talking about critical success factors. They are explained in white papers and webinars (and on blogs like this one). In order to succeed, organizations not only need to know what to do, but they also need to know what NOT to do. In your experience, what are the three biggest mistakes an organization can make when making the move to content management? And, better still, what are the implications of each of those mistakes and how can they be avoided?
Craig: First, don’t go for the big bang implementation in one go-round. More specifically, tying the deployment too closely to major production deliverables may catalyze a sense of urgency to get the system running, but this most often leads to sacrifices and shortcuts in the configuration and change management plan that actually slow down adoption and realization of benefits. Instead, start with a smaller project that exercises the full scope of the system and its processes. Apply Project Management resources to keep on track. Refine your work processes, develop training and rollout plans during this phase, then roll the system out to a reasonably sized group or team. Lather, rinse, repeat.
Second, don’t insist that the CMS automate everything and match your existing processes. This will lead to costly customizations of the software and limit its adoption. Having a broader perspective on Change Management as I mentioned before will help avoid this pitfall. Bringing in a CMS and DITA is a recognition that processes must adapt and change. The best approach is a balance of CMS configuration settings plus adapted work processed that get your system running in the minimum amount of time.
Third, don’t forget to “sweat the details” during the configuration and initial deployment phase. Spend the time to exercise the key CMS workflows and processes fully to make sure they integrate effectively with other external work processes and organizations. Conversely, don’t ‘sweat too many details’ by trying to detail out every possible process. Just focus on the ones that are important to your needs.
Chip: Experts I’ve interviewed previously have pointed out that cultural and organizational factors can impede content management projects because they introduce changes that are, to say the least, challenging for some organizations. That’s definitely true. But, I don’t think there’s enough attention being paid to the changes content management creates for content contributors. The one that comes immediately to mind is the importance of recognizing that not all writers can easily adjust to writing topic-based, modular content appropriate for reuse. What types of changes should technical documentation, training, and support center managers be aware of?
Craig: Managers must plan time to gain a thorough understanding of the shift to topic-based writing by establishing best practices, providing author training and ongoing review processes to monitor and manage the shift. This should also be applied to understanding DITA’s separation of presentation from content.
Given the importance of these changes and the need for a smooth transition through this shift, I also think these considerations should be part of the overall Change Management Plan. Documentation, Training and Support managers should seek assistance with Change Management from their Company’s Project Management Office and/or some external consulting for advice or help with execution.
Chip: Things are certainly changing rapidly in the content management software arena. We’ve made big changes here ourselves. At Astoria, we have made the move to the hosted content management system model (often referred to as Software as a Service or Saas), an approach that provides on-demand access to the content management system via the web. This is good news for companies who have content contributors who work in geographically dispersed areas, and for those who travel and need access to the system. It’s also a big selling point for those organizations that don’t want all the hassle of installing and managing the system themselves. When an organization adopts a hosted content management solution, what responsibilities are transferred to the SaaS provider? And, what are the not-so-obvious benefits of this increasingly popular approach?
Craig: At Astoria, we are fully responsible for the overall operation of the system. This includes ensuring that the system is always available at or above the promised service level (at Astoria its 98.5% uptime). Because our business and our revenue stream is dependent on the reliable, secure operation of our CMS application, our CMS users have told us we often provide better service levels (less downtime and faster response times) than for in-house applications managed by IT.
There are also benefits for a Customer’s IT organization as well. In addition to not having additional servers to manage, maintain and back-up, the IT organization does not need to train any of their already stretched resources on the lower level application administration, configuration and tuning aspects of the CMS.
Astoria’s personnel ensure that the CMS is optimally configured and updated at all times. The SaaS approach ensures a reliable, available solution to CMS users while allowing IT to focus on their core areas of technical expertise.
Chip: What advice do you have for managers who are struggling to make the case for content management in their organizations? What can a manager do to make the business case for content management?
Craig: Examine the whole business process behind the creation, review, distribution and maintenance of technical documentation. Since the technical documentation process has many cross-functional interactions, include the many stakeholders that touch the process like engineering, marketing, production and most importantly, the consumers of the documentation, your end-users or Customers. Consider the use-cases that drive your publications process: change orders, new product releases and delivery media types.
A strong business case will include tangible improvements in areas such as: faster product release and maintenance cycles, efficiencies gained through content re-use/single-sourcing, reduced costs of translation and publication. These specific benefits should be measurable and lead to financial benefits. This type of analysis will help reveal the hidden costs and inefficiencies that can easily be improved by a CMS. This is especially revealing when those costs are borne or incurred by other organizations. For example, a last minute engineering change order might require separate re-editing and review of the web, pdf and hardcopy media. Depending on priorities, this could lead to a delayed product shipment impacting sales, or inaccurate documentation impacting serviceability and Customer Support, or incur additional re-translations costs.
Finally, once a solid business case is in place, conduct a pilot project focused on validating the key benefits that are expected. Doing so will help you understand how best to scale up your implementation and plan your full production rollout.
Chip: Craig, thanks for sharing your lessons learned with us. I really appreciate it.
Craig: No problem. I really think this subject is an important one that more and more technical documentation managers will be forced to address as they make the move to content management. I'd like to encourage your readers to check out our webinar archive where they learn more about several of the issues I discussed with you here today.
