Conference notes from: Content Management Strategies/DITA North America 2010

The CMS/DITA NA 2010 conference was full of lessons learned and pain, but there is light at the end of the tunnel. The successful projects were those who had properly socialized the impact of the project to all parts of their organization.

by Liz Fraley

For the last decade I have made a regular habit to speak at or at least attend the CMS conference. I think I only missed one year. It gives me an interesting perspective because I can see trends over time, changes in presentation themes, popularity of topics, and the changing interests of the attendees.

For the first year, DITA seemed more of an assumption than an experimental technology. More companies are in year 3-5 of their implementation. In years past, the message has always been: Why choose DITA? What’s the value proposition? This year, the message was lessons learned. The biggest lesson learned was that you can’t treat a DITA implementation like a line item. The projects that were successful were those that had properly socialized the impact of the project to all parts of their organization.

For example, Catherine Lyman (NetApp) said she’d done a fantastic job socializing the impact and the value of their DITA implementation all the way up the chain. Her CEO really understood exactly the value behind their effort and exactly what benefits this shift was bringing to NetApp’s business.  However, she hadn’t socialized to lateral departments and every time she brought the project to a new group, she had to start from square one and begin the buy-in discussions over again. It slowed down adoption across the company and, as a result, caused a delay in the ROI she had projected. Her advice? Go to business and engineering groups early and be clear on the corporate drivers. Also, sell to the whole organization the benefits for their departments. Put customer-facing improvements first!

Successful projects place a high emphasis on collaboration and socialization. It was a story we heard over and over at the conference this year. Intel was starting over again — going back to square one — because they weren’t getting the system they needed to really serve their business goals. They hadn’t originally defined their requirements well enough to really evaluate the vendors. They focused on tools first. As a result, they have worked out a set of vendor questions to envy. They included these questions in their slides for the attendees of CMS/DITA NA 2010.

HP talked about the importance of collaboration within your team and with other groups in the enterprise because reuse is a cultural issue. You need to build trust and structure so that you can measure and track effectiveness.

Actuate said that they were also back at the drawing board. They had overused FrameMaker’s tools to the point it wouldn’t compile correctly and they’d get spurious content. They recommend moving to a robust, enterprise-level, dynamic publishing system with a DITA-aware editor built to do it from the ground up.

Rebekka Andersen, a professor from UC Davis, presented her research into why CMS adoptions fail. She followed a company from the early stages through their CMS evaluations and participated in the discussions every step of the way. In this case, the team not only decided against the vendor’s tool but also against CMS in general, but the reason why was not what anyone could have predicted. Her conclusion? The prevailing tool-focused approach to implementation. Don’t let tool define you: it should be the other way around. Her advice? Understand that technology can’t solve the problem or save the day. Your focus should not be on the tools. Tools should be <10% of project implementation; 50% of any implementation is change management and 40% is process management.

There was one presentation on using Sharepoint as a CCMS. If you just see the slides, it comes across as a success story, but the reaction of the audience (and the talk track behind the slides) made it clear that it really wasn’t. Not from any perspective except for the highly-paid consultants doing all the Sharepoint development ($$$$).

Me? I told success stories this year of companies who were 10+ years into their Arbortext/XML authoring implementations. You can find the slides and abstract here: Where Are They Now. After my presentation, Charlotte Robidoux (HP) said that she was glad someone was telling success stories. The conference was full of lessons learned and pain, and it was good to see that there is light at the end of the tunnel.

To put it in the words of some of the longest-running Arbortext customers that I interviewed for my presentation:

“This is all doable because we went to XML and Arbortext in 2004”

“This is ‘bottled gold’ because it gives us a HUGE advantage over our competition”

Overall, it was a great conference. The returns really are there if you frame your project as something that has enterprise-level impact (which it does).

The Single-Sourcing Triangle is more of a Pyramid

Understanding the triangle — technology, theory, tools — is essential, but you cannot stop there. The triangle exists in time and space: it lives, breathes, and survives in the context of your business. The triangle is the foundation. When you understand how each side the triangle fits the goals and needs of your business, you’ve guaranteed your success.

…is really more of a pyramid

The single-sourcing triangle is the foundation to make single-sourcing projects succeed. All three sides of the must work together to create a solid foundation for your project:

  • The Single-Sourcing TriangleSide #1 – The Theory Side:
    The Information Management Consulting Companies
  • Side #2 – The Technology Side:
    Programming Nuts and Bolts
  • Side #3 – The Product Side:
    Vendors and Application-Specific Specialists

Successful single sourcing requires competence and execution on all three sides of the single-sourcing triangle.

First, the information itself (the content) must have real structure. Information management consulting companies can help your various writing groups organize their content and think about it in new ways that promote single-sourcing activities.

Second, you need software engineers and IT folks to make sure that both the hardware and software infrastructures support single-sourcing activities.

In addition, these folks must work closely with the vendors (Side #3) chosen through rigorous requirements matching, to make sure that all the different systems play well together. Over-engineering your triangle (excessive customization) will produce systems that prevent you from extending your single-sourcing system to interact with other business entities, essentially stifling any future process innovation.

Understanding the triangle is essential, but you cannot stop there. The triangle exists in time and space: it lives, breathes, and survives in the context of your business. The triangle is the foundation. When you understand how each side the triangle fits the goals and needs of your business, you’ve guaranteed your success.

Go single vendor or go toolbox? (build vs buy)

Summary: Do you build or buy? What’s the true cost of integrating different product from different vendors? What are the ramifications for integration and process flow? And how do you make that determination?

Recently I’ve had the opportunity to think about my first single-sourcing project and the way we went about it.

Silicon Valley is notorious for being a difficult place to sell software into: You can’t throw a rock on the street without hitting 10 software engineers (today, 3 of them are looking for work). And, as a result, there’s culture of do-it-yourself that is magnified because implementation and customization work is work that software engineers do.  Although this situation is magnified in the valley, it’s not unique to it. In this economic climate, the pressure to leverage existing resources is tremendous everywhere.

So I took the time to sit back, think about what our true costs were to do things the way we did. It’s the classic discussion: build vs buy. And, until the last several years, I’d thought we’d done it right.

Now, I’m convinced we didn’t.

As a full-time employee, hired to make the project come together, I saw the cost of the tools as the only cost. I saw the resources at my disposal—me, IT, people I knew in engineering, the skills and technical bent of the writers in the group—and I saw the cost of tools vs the cost of the enterprise system. We had done a deep dive into the organizational requirements we’d need to get it done. We knew how content was created and delivered in every part of our organization.  However, because I didn’t socialize it properly—because I let myself and my management be distracted by the technology—it took far longer to complete and cost far more than it should have.

While I can say I learned a lot through trial by fire, the full cost of implementing the system the way we did was a lot higher than the cost of purchase would have been.

Most Techpubs departments don’t get the luxury of having a software engineer dedicated to their needs. Writers are typically tasked to add tool admin and implementation to their ever growing list of responsibilities. Many writers stop being writers entirely. The don’t get to generate, architect, and design the company’s information strategy, they end up tied to implementing and maintaining the toolset.

This gets more and more difficult the more content you have. As the need for a real information architect grows—as it always does—the ability for that tools-focused writer to have any part of the content side of things falls away to nothing.

It took 4 years from concept to stable, production environment. The costs included my salary over those years. The time from several IT staff members at the beginning and over time sustaining and making process changes. The time from engineering staff who were co-opted here and there along the way. The time from engineering staff was an invisible cost—it didn’t show but it diverted their much more valuable time from product development to tool implementation and maintenance.  This is one cost that is extremely expensive to the company that we’re all quick to ignore when we’re not thinking of the larger business needs.

If we had gone the enterprise route, bought a ‘system’ that we could leverage out of the box, we’d have seen ROI in 2.

4 vs. 2: That’s an expensive lesson.

In this economic climate, it’s very easy to ignore the hidden costs of toolbox solutions. Enterprise solutions are more expensive than toolbox solutions, but they have a different goal—for a reason. And worse still, it’s easy to be distracted by the technology and miss the organizational needs that drive the need for a single sourcing system.

They’re value is in are things like these:

  • Eliminating manual effort
  • Simplifying product version– or configuration-specific deliverables
  • Tracking when product changes requires documentation updates
  • Automatically identifying all affected documents when changes occur
  • Integrating all of the components up front and building solutions that work together out of the box.

Every situation is different. If you’ve got a software engineer, or a writer that wants to be one, then your choices are different from the group that doesn’t have the funding to get support from IT. Doing more with less applies to products as much as to staff members. Less hassle, less implementation work, less sustaining costs year after year all mean that you are doing more with less.

In an enterprise solution like Arbortext, everything is tested together, deployed together, and upgraded together. In other words, enterprise software vendors have done the work of building the system so that you don’t have to.