Best Practices for Implementing a CMS for Technical Publications – Part 2

Home/Publications/CIDM eNews/Information Management News 10.06/Best Practices for Implementing a CMS for Technical Publications – Part 2

Scott Wahl, Research in Motion, Ltd.

Part 2 of 3 – Planning a CMS

Organize a team of people who lead the content-management project. Consider carefully who will be most constructive in driving the project forward while making sure you have representation of all affected teams. In particular, make sure to include people from these teams:

  • IT – you will want their help later on to implement a system, so include them at the start
  • Writers – include at least one writer from each major team that will use the system
  • Editors – include at least one editor
  • Translation managers – include the person who manages documentation translation

The trick, as with any project team, is to keep the team small enough to work productively while ensuring adequate representation.

Make sure you define expectations for the team in advance. Will anyone be dedicated to the project? What percentage of time do you expect people to be spending on the project? If everyone does not report to you directly, does each person’s manager support their involvement in the project?

In addition to setting up the project team, identify key external stakeholders who you will want to keep informed as the project progresses. Stakeholders often include other departments that might want to use the content-management system in the future, internal customers of the content your department produces, and customer-facing teams.

Write a Business Case and Get Buy-in

Once you have set up a project team, you need to write a business case. The business case serves two purposes. First, it helps you justify the project (and the associated costs) to senior management and others in the organization. Second, it helps set out the overall objectives of the project, which will help define the scope and detailed requirements of the project and help keep your team focused.

The main sections to include in a business case are as follows:

  • Project Purpose
    Explain, as concisely as possible, the key reasons for implementing a content-management system. In particular, explain why the system is necessary now and how internal and external customers will benefit.
  • Environmental Analysis
    Consider the macro-environment in which your organization is operating, as well as the specific situation of your department. What are the business opportunities that your department must help your organization address? What are the technical limitations of your current authoring and publishing tools, and how do they impact your department’s effectiveness?
  • Competitive Analysis
    If you can, describe how a content-management system will help your organization, however indirectly, gain or keep a competitive advantage. How will a content-management system help your department add value to your customers? How will customers benefit? Consider industry trends.
  • Return on Investment
    Perhaps the most important part of the business case is a return on investment (ROI) analysis, in which you provide a detailed estimate of both expected costs and expected savings and show the return on investment expected after the system is implemented. Include the payback period—the number of years it will take to pay off the initial investment.Costs include purchase of software licenses, annual software maintenance, hardware servers, consulting and training, salary costs for people to work on the project, as well as any translation setup costs. Cost savings include both external savings (typically related to translation) as well as internal savings related to writing, editing, and review time that you expect to save.

When you have written your business case, meet with your senior management team to review it with them. Get their feedback on any information in your business case that needs clarification or further explanation. Obtain their approval to proceed with the project on the basis of the budget and ROI analysis you have presented.

Define an Overall Schedule

As with any large project, it is important to set out a high-level schedule. Be realistic about how long it will take to evaluate and select vendors, complete a pilot project, and do the necessary analysis to start moving some content into a production system. The schedule will help you set expectations with senior management and other stakeholders about how long the project will take. Remember that the project will almost certainly take longer than you think.

Define Requirements

Working with your project team, define detailed requirements for your content-management system. Include both business and technical requirements. Specify requirements related to each component of the system you are planning to implement, including authoring, content management, publishing, translation, and reporting. Also include any IT requirements, especially those related to access from remote locations, system performance, and failover.

Getting the requirements right at the start of the project is critical to your success. The requirements will drive everything that comes after—from evaluating and selecting software through to defining the success criteria for the pilot and writing test cases.

If possible, agree on the relative priority of each requirement, either on a scale of 1 to 5 or simply by distinguishing between “must-have” and “nice-to-have” requirements. Setting priorities now is important so that when you go to evaluate vendor proposals, you can make decisions objectively.

Send Out a Request for Proposals (RFP)

Based on your requirements, write a request for proposals (RFP) to send out to potential software vendors. You can determine the potential list of vendors from various sources, including conferences and industry web sites. Send your RFP to no more than 10 companies.

Contact your IT team to see if your company has a standard template or process for RFPs. Make sure that each vendor signs a non-disclosure agreement (NDA) before receiving the RFP, if that is your company’s policy.

The RFP should clearly define the purpose and scope of your project. It should ask vendors to provide details on their product, identify whether it meets each requirement, and provide detailed pricing, as well as training and support plans. The RFP should also ask companies to provide additional information about the company and its financial performance, and to list customer references.

It is important that an RFP maintain transparency and fairness among bidders. In your RFP, clearly state how vendors should contact you with any questions. When you answer a question from one vendor, send the same information to all other vendors as well. Also, specify the deadline by which proposals need to be returned and the format in which you want to receive them (by email, mail, or fax).

Evaluate Proposals

When you have received proposals from all vendors, work with your project team to evaluate and compare the proposals. Often you can discount some proposals immediately based on price or must-have requirements that are not met. Come up with a short list of vendors (typically no more than four). Inform those vendors that did not make your short list with a brief explanation of your decision.

Invite each vendor on your short list to come to your company for a half or a full day to provide a detailed product demonstration. It is often a good idea to provide a script to these vendors so that they show you want you want to see, not what they want you to see.

During these face-to-face meetings with each vendor, don’t just spend time discussing the product. Ask each vendor to explain how they see the product evolving, what sort of custom work they would expect to have to do for you, and how their company provides ongoing support.

Based on the vendor demonstrations, choose the vendors you want to proceed to a pilot project. Make sure that your team arrives at a consensus decision. Give everyone time to express their views, and make sure you document your team’s discussion and decisions for future reference. Take as much time as you need. Choosing a vendor is a critical step in the project.

Keep the following in mind when you choose vendor(s) for a pilot:

  • Make sure that all of your “must-have” requirements are met.
  • Make sure you understand what level of customization will be required.
  • Choose a company with people who you trust and look forward to working with.

The last point is very important; any content management system will require some level of customization to make it work the way you need it to. So, unless you choose to use a third-party systems integrator, you will be working closely with the software vendor.

If the team agrees that one vendor is clearly superior, then proceed with only that vendor for a pilot project. If there are two vendors who are very close, you also have the option of doing pilot projects with both vendors concurrently—this will obviously add time and effort to your project, but it might be the only way to arrive at a clear decision.

Conduct a Pilot Project

Before you purchase any software, conduct a thorough pilot with the vendor(s). Make sure that the vendor(s) agree to conduct a pilot project with you before you purchase the software, and make any eventual software purchase contingent upon successful completion of the pilot.

Hold a kick-off meeting with the vendor to start the pilot project. Define key objective criteria for the success of the pilot, and get the vendor to agree to those criteria. It is important that both you and the vendor agree on the scope of the pilot so that you both know when you are done. Typically, the pilot will focus on standard product functionality, even though you will often know of custom work that will be required eventually.

Set aside time and resources to implement the software in a pilot environment, conduct testing of the pilot system. Write detailed test cases for each of your original requirements, and involve the whole project team in the testing. Consolidate test results and provide those back to the vendor.

Choose Vendor(s)

At the end of your pilot, make your decision. If the pilot was successful, then you are ready to purchase software and start on the next phase of your project—implementing the system in production and starting your content analysis.

Scott Wahl is Director of Software Documentation & Localization at Research In Motion Limited (RIM). RIM recently implemented a content management system based on DITA XML. These articles represent the personal opinions of the author and are not in any way endorsed by Research In Motion Limited.