A Documentation Organization Odyssey


June 2006

A Documentation Organization Odyssey

CIDMIconNewsletter Delise Jung, Deborah Silvi, and Beth Thomerson, BMC Software

BMC Software sells systems management software to large companies around the world. We’ve been in business for 25 years, rather successfully selling a large number of individual point products. But the market we address is shifting—customers are demanding integrated solutions, not stand-alone products.

In response to shifting demands, a few years ago our company shifted its sales and marketing focus from selling many point products to promoting “solutions”—known as BSM Routes to Value™—that enable our customers to manage specific problems within their IT environments. We call this Business Service Management (BSM). BSM ensures that everything IT does is prioritized according to business impact, enabling IT to proactively address business requirements to lower costs, drive revenue, and mitigate risk.

Although our sales force had begun selling integrated solutions to customers, the R&D organization continued to operate in both geographic and product silos. Consequently, our writing groups were organized by product offerings, or lines of business (LOBs), with a writer assigned to one or more product teams to produce all of the technical documentation for individual products.

To support their assigned products, writers focused on providing comprehensive documentation coverage for every product. Writers tracked the product’s functionality changes and enhancements and planned to update existing books and help systems to reflect those changes. In essence, we operated in the “same old” way by aligning our work with Development and producing information so that it was ready to release with the product. Unless a product integrated with other products, we weren’t aware of what was going on with other products in the company’s portfolio—after all, just getting our own deliverables out the door was exhausting enough, right?

Although we reported to one centralized Information Development organization, each of our teams still focused on the needs of and requests from Development and Product Marketing for our particular LOB. We lacked a clear understanding of how each LOB compared to others in terms of resource priorities and current and projected revenue. We also lacked a detailed understanding of how the various products in our business unit fit into the BSM and Routes to Value models.

Our lack of focus on product lifecycles and profitability was aggravated by diminishing writer and editor resources. As with many software companies, ours regularly reduced staff without decreasing the number of supported products or release cycles. We continually had to do more with less. We sacrificed editing positions in favor of writing positions, although we knew how much editors contributed to the quality and consistency of documentation. Sadly, the proportion of editors to writers steadily fell.

As our company continually added new, strategic products to our workload, we struggled to provide the usual comprehensive documentation. We found that “struggle” was the operative word and, unfortunately, truly reflected our everyday lives. We realized that continuing to provide traditional documentation in a traditional way was a losing battle. Something had to change. So WE changed. We forced ourselves to look at our situation from a new perspective and to take stock of what we were doing and how we needed to change. As a management team, we started brainstorming to figure out why what we were doing was no longer enough.

Questioning the Status Quo

Up to this point, we had never differentiated our deliverables to account for where each product was in its lifecycle, how much profit margin that product contributed, or its strategic importance to the company. We didn’t take into account that for new products, customers primarily want to know how to get them installed, configured, and running quickly—in other words, they want to see a quick return on their investment. With use, customers learn more about the product, and their documentation needs grow. But initially, customers don’t need huge books and help systems containing information about every feature, function, and detail.

We also didn’t take into account that our mature products already had comprehensive documentation, usually covering concepts in great detail. They also had an experienced customer base already familiar with our products. What these customers really need to know is what’s new and what’s changed in a given release, and they want to be notified quickly when issues arise with their products: how to resolve issues, try available workarounds, and get patches they need to apply for their environment.

In addition, we spent very little time understanding or documenting the technical details of how our various products work together to help our customers achieve true BSM or maturity within a particular Route to Value. Instead, we left such “integration” information up to Sales and Technical and Professional Services to develop. Because these groups spend almost all of their time on the road at customer sites, they don’t have the time, resources, or expertise to develop the appropriate information deliverables that would help customers understand—and buy—our products. So generally, this type of material simply didn’t get created.

As we met to discuss all of these issues, we became painfully aware of gaps in our coverage model, gaps that didn’t address varying customer needs or our new strategic corporate focus. These gaps were certainly unintentional. During the past few years, we had researched and analyzed customer feedback regarding documentation requirements, current deficiencies, and recommendations for improvement. Although some writers made headway in implementing improvements, most found it difficult to manage with shrinking time and resources.

So we knew what our customers wanted, that our writers craved the opportunity to develop more detailed, innovative information, and that we needed to support our company’s BSM vision. Although we were slowly closing documentation gaps, implementing improvements, and providing limited product integration information, it was taking too long and frustrating internal and external customers and our writers. We needed to jumpstart the evolution.

The Solution

As soon as we started brainstorming a solution, we got serious about effecting change. Managers spent several weeks discussing how to create a new organization and a strategy for making it reality. We determined how to address different customer needs, different stages in the various products’ lifecycles and levels of profitability, and the company’s BSM vision, while being cost-effective and maintaining documentation quality. Our solution was to align our writing groups around types of information deliverables rather than lines of business.

Our objectives were to

  • address the corporate BSM message and show how BSM Routes to Value benefit potential and existing customers
  • tie our work inextricably to revenue and sales, as well as product lifecycles
  • provide deliverables from the customer perspective rather than from the development and product perspectives
  • ensure quick product deployment and Return on Investment (ROI) to new customers
  • proactively provide quick problem-solving for existing customers
  • strengthen and deepen customer advocacy
  • provide targeted, cost-effective classic documentation for existing customers
  • strengthen limited editing resources and maintain quality deliverables
  • introduce stronger efficiencies and collaboration across the company
  • broaden writer and manager perspective about all products

We divided our organization into four groups with different internal group alignments:

  • The Routes to Value team provides internal and external technical solutions and product integration information through white papers, articles, and online communication avenues—aligned with our Corporate Marketing organization.
  • The Return on Investment team provides installation and getting started information, best practices, architectural diagrams, demonstrations, and quick reference—aligned with Product Marketing, architects, Development, and customer education.
  • The Customer Response team provides solutions, workarounds, troubleshooting information, notification of patches using bulletins, creation and maintenance of a single knowledge base, and message boards—aligned with Customer Support, Product Marketing, and Technical and Professional Services.
  • The Classic Documentation team provides information about what is new and what has changed for mature products that have a complete documentation set—aligned with Development, QA, Customer Support, and Product Marketing.
  • We slightly adjusted this structure to accommodate international geographic considerations. We kept our Israel and India writing teams together for management reporting and designated within the Israel team specific writers to focus on Return on Investment, Customer Response, and Classic Documentation needs. However, we intentionally treated the US as a single location; all US-based managers now manage remote employees across multiple sites (Houston and Austin, Texas; Waltham, Massachusetts; and Sunnyvale, California). In addition, we consolidated the remaining editors in order to maximize their effectiveness and efficiency. Though few in number, these team members add much value to our efforts.

Benefits Realized

Our new organization offers many benefits to internal and external customers and to writers. Customers now have more streamlined documentation targeted to their needs. Existing customers receive a quicker turnaround for product issues, solutions, workarounds, and troubleshooting. These customers also get targeted information about new and changed functionality and features, which eliminates their need to wade through large amounts of static, mature documentation. New customers benefit from a stronger focus on installation, configuration, implementation, and best practices. Finally, all customers benefit from a stronger connection to BSM and our Routes to Value.

Although the initial response from some internal teams was fearful (some worried that they might lose writer expertise in products and lines of business), these teams soon realized that they actually gained more writers who were knowledgeable about their products. Writers producing specific documentation deliverables for many products might not initially be product experts, but they could quickly produce targeted documentation for different customer situations. Also, all writing managers were now aware of and somewhat knowledgeable about multiple teams’ products and plans, and could provide a central point of coordination for documentation across our entire business unit.

Return on Investment and Classic Documentation writers can now maintain their focus on product features and functionality and the milestones associated with tight product release schedules. This focus has been especially important in our newly adopted Agile development environment. Customer Response writers are available to quickly address unexpected customer pain points, and the Routes to Value writers are focused on solution- and market-based information deliverables.

All of our writers have been invigorated with a new mission that ties directly into the company’s strategic vision. They no longer feel like “order takers,” but rather like active participants in decision-making. In addition, all writers have the opportunity to learn about multiple products, which increases their value to the company. Transferring knowledge and workloads during writer absences is now much easier.

We are approaching the one-year anniversary of our new organization. It is a success; writers, editors, and managers are excited about their jobs again, development team members are supportive, and our CEO bragged about our innovation in a recent company-wide meeting. Long term, of course, we need to gather customer metrics that show improvement and satisfaction so that we can tweak our organization to be even more responsive and successful. To change so drastically was daunting, but to do nothing was worse. Taking chances and being daring has transformed us, and we are looking forward to our future—which looks bright indeed. CIDMIconNewsletter

About the Authors

Delise Jung
BMC Software, Inc.
Technical Publications Manager

Delise Jung leads a team of technical writers and program managers for the Distributed Systems Management business unit at BMC Software. Delise is currently bringing her diverse skills to bear on the newly formed “Routes-to-Value” information team. These seasoned writers create technical materials that bridge the information gap between individual product documentation and BMC’s corporate strategy materials.

Deborah Silvi
BMC Software, Inc.
Technical Publications Manager

Deborah Silvi is a Technical Publications Manager at BMC Software, where she has worked for the past 12 years as a writer and manager. She manages the Distributed Systems Customer Response writing group, which produces product and functionality-specific documentation deliverables based on customer input, rather than product development. She has been in the technical communications profession for nearly 25 years, in consulting and corporate staff, with most of her experience in software development. She is an STC Associate Fellow, with a special interest in community and corporate relationships.

Beth Thomerson
BMC Software, Inc.
Technical Publications Manager

Beth Thomerson is a Technical Publications Manager at BMC Software, where she has worked for the past nine years as a writer and manager. She manages the Distributed Systems Return on Investment (ROI) writing group, which produces product and functionality-specific documentation deliverables based on customer needs, to ensure fast ROI. She has been in the technical communications profession for over 18 years and is a member of STC.