Content Collaboration at Citrix: Strategic insights

Home/Publications/Best Practices Newsletter/2011 – Best Practices Newsletter/Content Collaboration at Citrix: Strategic insights

CIDM

February 2011


Content Collaboration at Citrix: Strategic insights


CIDMIconNewsletterMathew Varghese, Citrix Systems, Inc.

I generally tend to be cynical about marketing terms. So, when I added the tag line “Strategic Insights,” I did so with some trepidation because the insights seemed so simple—at least in retrospect. However, I feel that these insights will be useful to those who haven’t yet started collaborating. For those who have been collaborating for a while, these points might simply reinforce the fact that they are on the right track!

This article is divided into three sections. The first section is a very quick overview of the collaboration initiative at Citrix, the teams involved, and the collaboration process. The second section covers the history of content collaboration at Citrix. The last section covers the insights.

A Really Quick Overview

In the past three years, content collaboration has become an integral part of the content development process at Citrix. A group known as the content council manages the collaboration process. The council has representatives from the product documentation, education, customer support, product management, and marketing teams. A new council is set up for every product release. A content architect facilitates the activities of the content council. The goal of the council is to ensure content sharing and reuse and effective content delivery for a release.

Content reuse is achieved by breaking a deliverable down into reusable content artifacts and then assigning the artifacts to volunteers from different content development teams. For example, if a feature can be described using some conceptual information, a diagram, and a few configuration samples, the product documentation team creates the conceptual content and the diagram, and the customer support readiness team creates the configuration samples. This way, we manage to leverage the core skills of each team. All these artifacts are stored in a central SharePoint repository. Teams reuse the artifacts, thus ensuring consistency and accuracy. This form of reuse also ensures SME productivity, because artifacts once signed off are not reviewed again, no matter how many times they are reused. In addition to their regular deliverables, volunteers from the collaborating teams also create value-added deliverables like videos, podcasts, and articles. These value-added deliverables have helped lower support calls and have helped sales teams in their presentations and Proof of Concepts.

Quick Recap

Team—Content Council

Roles and Responsibilities

  • Content Architect—Facilitates collaboration by setting up content councils, running meetings, and setting up and maintaining SharePoint portals.
  • Product Manager—Reinforces vision and sets priorities by highlighting key features in a release and sharing business cases.
  • Release Manager—Provides project timelines and status updates from the engineering team.
  • Council Member—Represents teams, shares status updates, and develops reusable content artifacts.

Process

  1. After the engineering team begins work on a new release, the content architect sets up the following:
  • Content council
  • SharePoint portal
  • Kick-off meeting
  1. At the kick-off meeting:
  • The product manager for the release provides a high-level overview of the release. This overview includes a description of the key features and the market and user segments being addressed.
  • The release manager presents a high-level project plan.
  1. The meeting is recorded and posted on the SharePoint portal.
  2. The Content Council then meets once every two weeks to exchange notes. SMEs are invited to make presentations on key features, and other content developers are invited to attend and participate in the discussions. Product managers also join in these presentations and present business cases for the features being presented. These presentations have proven to be of immense help to all the content development teams. The sessions are recorded and serve as raw material for content developers. The content council meetings provide the council with a clear vision of the release. Sharing a common vision has been key to the success of this initiative.

History of Collaboration at Citrix

The work culture at Citrix has always been conducive to collaboration activities. The hierarchy is flat, people are approachable, and the management encourages collaboration at all levels. This situation is largely because Citrix’s fantastic growth in the past five years has been inorganic—fueled by the acquisition of several startup companies. The open culture at Citrix has been a key reason behind the quick amalgamation of these disparate cultures into a single cohesive unit.

How It All Began

Our collaboration efforts began over three years ago. I used to manage the documentation team then, and we were running into customer complaints about articles on the Customer Support site that were often out of sync with the documentation. We also received complaints from the engineering teams that they were receiving requests for information and reviews on the same subject from different teams. My investigations brought me into contact with the larger content development ecosystem that I had only vaguely heard about all along. Our teams were relatively small then, and locating people was easy. I managed to identify representatives from two of the key content development teams—education and customer support readiness. The Education team creates courseware for the Citrix certification exams, and the Customer Support Readiness team trains support personnel. So, after a few face-to-face meetings, we were all convinced that sharing information about what each of us was up to would save the SMEs and us a lot of time. So, we began our collaboration initiative by sharing feature lists. These lists were simple spreadsheets that contained a list of features that the documentation team was working on, key dates, and names of the technical writers assigned to each feature. We hoped that content developers from other teams would use this list to reach out to each other and share content.

Issues Encountered

This worked well initially. We all knew what the others were up to. However, some of the old problems still persisted and some new ones sprang up.

  • Developers were still receiving review requests for the same feature from different teams at different times.
  • Content reuse was still quite low.
  • Because teams had different deadlines, collaboration was often low.

Learnings

The first attempt at collaboration was not a roaring success, but it taught us several key lessons. While some of them look obvious in hindsight, they were not easy to implement at the beginning. The lessons we learned from our first attempt:

  • During the initial phase, collaboration requires a high degree of facilitation.
  • Content reuse is almost impossible without a central content store.
  • For content reuse to be effective, deliverables should be broken down into reusable “artifacts.”
  • Teams should share a common vision. They need to understand customer and market requirements clearly.

Content Collaboration Today

Our second attempt began early last year when the engineering team began work on a major new release. We decided to formally set up a content collaboration group for the release and called it a content council. The council consisted of representatives from the customer support readiness, education, product documentation, marketing, customer support, and product management teams. We had three main goals:

  • Share vision
  • Reuse content
  • Evolve innovative content delivery strategies

Sharing Vision

Information flow in an organization is often like a giant game of Telephone, and distortion is unavoidable. Content development teams often end up being the undeserving recipients of bad customer feedback. Most technical writers spend their entire careers facing comments like “I never read documentation.”

Most of these problems are due to the fact that content developers seldom see the “bigger picture.” Market segmentation, go-to-market strategies, and customer issues are confined to the boardrooms or management meetings. Content developers create content based on their understanding of the product. Often, different content development teams have differing views of the product and its features, thus inadvertently creating disparity between deliverables.

To counter these issues, we decided to rope in teams that interacted closely with customers and helped define product strategy. These were the product management, marketing, and customer support teams. Members from these teams provided the content council with the vision, go-to-market strategies, and possible customer expectations for each release. The product management and marketing folks helped us identify strategic features that would be marketed heavily. They also helped choose appropriate user scenarios and examples. The support engineers were able to anticipate the needs of customers better. They enriched the content by adding notes and tips that we would never have thought of otherwise. By sharing a common vision, content development teams have been able to create richer and more effective content.

Reusing Content

The content development ecosystem in an organization comprises content development specialists working in silos. Some of the traditional content development specializations include technical writing, courseware development, and training. In addition, even marketing and graphic design are content development functions. We realized that through content collaboration, we could leverage this diverse skill set to produce high-quality deliverables. So, the main goal of content reuse was to assign artifacts to volunteers who were best suited to develop them.

Developing a content reuse process was tricky. We encountered two key issues:

  • Tools and processes—On one hand, we didn’t want to force people to copy from each other’s deliverables. Not only was that a clumsy proposition, it also made measuring reuse difficult. On the other hand, we didn’t want to force them into using a centralized system like a CMS, because that would involve a steep learning curve that many teams did not have time for.
  • Features—Every product release had a large number of features, typically over 100. Tracking reuse for such a large number of features was a very tough proposition.

So, instead of being overambitious, we decided to keep the effort manageable and effective by focusing on a few key features and reusing content for them. We began by getting the product managers to identify key features for us. Then, we broke every feature down to discrete reusable artifacts and assigned them to different teams. The documentation team offered to develop conceptual information and diagrams; sample configurations went to the education team; and the customer support readiness team took the use cases. All this was captured in a “content plan.” To ensure transparency and easy access to information, we set up a SharePoint portal for each release. We used the portal to publish plans, meeting invites, and, most importantly, reusable content artifacts and deliverables. So, by choosing a few key features and assigning the development of reusable content artifacts to experts, we were able to achieve better quality and productivity.

Proactive Content Delivery

One of the key causes of customer complaints is not bad documentation but the customers’ inability to use the product. So, content development should be seen as a usability initiative and not as a support function.

Traditional content delivery is almost a reactive process. Teams create fresh content or update existing content every time there is a new product release. Formal content development teams like product documentation and courseware follow highly structured writing styles that leave little room for creativity. As a result, product manuals often come across as being unwieldy and rigid. Customers, therefore, prefer unstructured and informal content sources like blogs and videos, produced by technical staff like support engineers, as they “cut to the chase.” Customers, especially technical users, tend to “trust” content developed by their peers rather than professional content developers.

We decided to adopt a more proactive content strategy. As part of this strategy, we decided to create screencasts, blogs, and podcasts to highlight new features in addition to our regular deliverables. These would be used to communicate tips, tricks, deployment examples, and so on—that is, content that couldn’t be covered in the documentation and courseware.

Proactive content delivery is a great way to create customer delight. It also encourages content developers to evolve innovative means of delivering content to the customer.

Insights

Content collaboration seems to be the next big thing in the writing world today—almost as big as Web 2.0 is in the Internet space. In this section, I present the insights that I have gained over the past three years.

Define Goals and Expectations

Collaboration is always a rewarding experience, but things can go wrong if teams don’t understand the needs of other participating teams. A content council is a group of equals, with every person representing a different set of requirements. While some teams might just want to use these meetings to gather more information about a product release, some others might attend to share content. So, it’s very important that the members express their expectations in measurable terms before or soon after the council is set up. While the council might not be able to satisfy everyone, stating a need can go a long way in measuring the success of the collaboration initiative.

A good way to state the need is by deciding on a clear objective for the content council. Here are a few examples:

  • Council members will share and reuse content pertaining to all key features in this release.
  • The council will build and maintain a list of SMEs.
  • The council will create and maintain a list of features and sample configurations for each feature.

The objectives can be more detailed if needed, but they should be very clear. That way, every participant will know exactly what she or he stands to gain from the council.

Practice, Process, … Tools

The best way to collaborate is to keep the engagement simple and straightforward. Because collaboration initiatives involve multiple people with diverse skill sets and varying levels of experience, processes and tools could actually hamper progress. So, content councils should focus on making collaboration second nature. Processes and tools should be used only to improve the effectiveness of the collaboration initiative.

Radical as it may sound, investments, especially in tools, should be kept low initially. Instead, teams should be encouraged to innovate using existing tools and processes. I’ve also noticed that smart people tend to be more productive when working in a collaborative environment than when working alone. Teams should, therefore, invest in improving inter-team communication instead of new tools. Here are some things that teams can do:

  1. Organize a yearly “content summit.” Teams and representatives should meet once a year to share insights and experiences.
  2. Build a common lab to build scenarios and test features. This action will ensure consistency across all deliverables.

Share Content AND Vision

Content collaboration just for the sake of sharing content can be a very shortsighted goal. For content to be effective, it should address the real needs of the users that the products were intended to fulfill. To ensure that all the teams understand the vision of the company, a content council should have adequate representation from teams that regularly interact with customers and track industry trends. One of the biggest advantages of involving these teams is that they help us understand the audience better. This understanding leads to better audience and task analysis—key ingredients in effective content development. These teams can also help identify key features that require better content. They can also help evolve better content strategies. At Citrix, we involve most customer-facing teams in our content councils.

Meet Regularly

Meeting regularly is key to ensuring the success of a content collaboration initiative. At Citrix, we meet once every two weeks and exchange notes. These seemingly insignificant meetings have gone a long way in strengthening the group.

Conclusion

Collaboration can be a rich and rewarding experience for both the individual and for the company. It improves productivity and reduces employee turnover. Collaboration can open up new avenues of growth and visibility for individual contributors. Collaboration initiatives take time to deliver returns, but the returns are often long lasting. So go ahead and build your own content councils and experience the magic of collaboration! CIDMIconNewsletter

Varghese_MathewMathew Varghese

Citrix Systems, Inc.

mathew.varghese@citrix.com

Mathew is the Content Architect for the Networking and Cloud division at Citrix. As a content architect, Mathew develops information models, runs content collaboration initiatives, and drives content strategy for his division. He is an ardent DITA evangelist and a staunch supporter of the open source movement. Earlier this year, he spear-headed the development of a graphical user interface for DITA OT and released it to the open source community. He is currently developing a DITA-based information architecture methodology. During his spare time, Mathew runs for ASHA <http://www.ashanet.org/index.php?page=about>. He is also an avid traveler and photographer. Mathew holds a bachelor¹s degree in electrical engineering and a diploma in general management from Indian Institute of Management, Bangalore.

 

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close