Welcome to the Astoria WebLog

In this Astoria Blogs interview, Craig Sato, Senior Director, Services and Support at Astoria Software shares tips and techniques designed to help documentation and training managers make the move to content management.

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.

Posted by Chip Gettinger at 12:33 PM | Permalink

A variety of Content Management Systems (CMS) exist today, providing a wide range of solutions to various content challenges. Each CMS provides a common set of features including -- but not limited to -- librarianship, version control, workflow, metadata, access controls, and so forth. Usually, a CMS is designed with a specific set of applications in mind: managing Web content, documents, scanned images, rich media, XML, etc. To expand into new markets, CMS software vendors oftentimes extend functionality though product development, partnerships, or acquisitions.

Not all content management systems are alike, however. They vary greatly in the ways that they manage the actual content itself –- the text, media assets, cross references, and links -- and how they manages the changes to these items over time. The ability to manage the changes to content over time is a key way to differentiate various CMS applications.

Demands of Dynamic Product Documentation

CMS applications to support Dynamic Product Documentation require very demanding approaches to maintain conformity to product releases. Typically, this content is delivered in multiple formats such as PDF, HTML Help, etc. and is subject to frequent changes/updates and requires tracking these changes at a very granular level.

Many of our customers need to maintain complex documentation sets. Efficiently managing the creation and delivery of these information products involves keeping track of multiple versions and the changes made to each, as well as publishing the right information for each target audiences in the appropriate languages. The ultimate challenge is to maintain older products (and their legacy documentation) at the same time you create and deliver newer configurations of the same or derivative products. These information products all share a common set of content and require a very granular management approach to track the differences and configurations for each release. These variants all need to map to customer deliverables and are typically published in multiple languages.

A dynamic solution calls for a very fine-grain content component management system to manage complex deliverables. These requirements go beyond a typical document or file management system. Dynamic content solutions need to manage the complex product variations, versions, languages and links typical of documentation, help files, service guides and training materials. Managing the relationships of the content and their changes over time requires extensive management of content components –- text, graphics, rich media –- and all of the links tying them to product deliverables.

Content component management systems like Astoria provide a very easy approach for creating and managing content for reuse. Components of larger documents (or components of DITA Topics) can easily be shared between deliverables. An advanced, object-oriented content component management system does not require you to define “minimal revisable units” or MRUs to reuse content nor do they need to “burst” a document into “chunks.” This saves significant time and effort when designing component reuse models and lets you easily adapt your reuse model in the future.

The higher percentage of reuse within a deliverable, the greater the consistency of information provided to your customer. Reuse also builds in protection from future product changes by minimizing the time required to make changes. With advanced content component management systems like Astoria, you can easily change the content reuse model without any programming or database administration. A component approach also provides applications with the ability to automatically assemble documents based on search queries, customer profiles, or specific content. This greatly expands the potential derivative documents that you can provide –- customers can receive custom- tailored documents on-demand designed to meet their specific needs.

However, not only are you required to manage component changes, but you also need to manage the changes to the component relationships over time. For example, a newer version of your product may have dropped support for Windows NT, but the older version continues to support it. Without a CMS, you are forced to mange two (or more) sets of documentation, even though 80 to 90 percent of it is identical. Differences usually are just in screen captures, procedures or menus. Add localization into several languages, and you have a configuration nightmare that can grow to become unmanageable when storing this content on a typical file system.

Finally, your customers do not want to figure out what documentation applies to the products that they purchased from you. Customer satisfaction surveys show that consumers believe that they are often provided too much documentation, much of which is not related to the specific version of the product purchased. Too often, they report, they are forced to cull through content that does not apply to them at all. This leads to customer dissatisfaction, and in many cases, increases in calls to your support center. In some circumstances, customers get fed up and take their business elsewhere.

“Ripple Effect” of Change Orders

Often in customer meetings the discussion moves towards the “ripple effect” that Engineering Change Orders (ECOs) have on documentation. Product changes always have impact throughout an organization. The closer it is to the product ship date, the larger an impact ECOs have on product documentation and the ability of the technical documentation team to manage updates in a timely fashion. ECOs have a compounding effect when content has already been sent to the translation vendor -– people have to work all hours of the day and night with costs skyrocketing. The better prepared you are to manage them, the smoother the process for implementation.

A component management system is designed from the beginning to anticipate the ripple effect providing several critical features to minimize their impact. First, you can quickly identify what content components are reused -- and where (and by whom) -- within the information products you create. When you update a source content component, it automatically updates all other references to it. In this scenario, only the source content requires review and approval, saving critical time. Finally, only the components that have been changed will need to be re-translated, again minimizing time as well as costs.

In conclusion, a content component management approach provides the disciplines of a CMS while providing an easy way to manage and adapt to future business requirements that were not relevant during your initial implementation.

Posted by Chip Gettinger at 09:00 AM | Permalink