Developing and implementing a content management system (CMS) is a multistep effort, involving deep investigation and review of everything from content strategy and requirements to attaining the all-important corporate buy-in.
The first step in any CMS project should be to define content requirements, a process I discussed in a previous article. If your organization has completed this phase, the next step is to determine and define the technical issues involved in the implementation of the CMS.
For advice on the technical aspects of a CMS project, I turned to noted expert Jason Meugniot, managing director and CMS Practice Leader at Guidance, an application development and systems integration firm in Marina del Rey, CA. Guidance has helped companies such as Foot Locker, The Right Start, and Universal improve the return on investment of customer-facing Web initiatives that include content management, e-commerce, and CRM.
In this article, Meugniot outlines how best to determine and define CMS technical requirements and the issues that can likely crop up during the effort.
TechRepublic: What mistakes do CIOs commonly make when defining technical requirements?
Meugniot: Defining content management technical requirements can, at first glance, appear to be a simple task for a CIO. In my experience, technology platforms, hardware and software procurement, and architecture design fall into the “comfort zones” of many CIOs. However, I am consistently surprised to hear CIOs put the cart before the horse when they ask me, “What do you think about Vignette vs. Interwoven?” or “Can you help me organize a series of vendor briefings so I can choose one fast?”
A host of tech needs to consider
TechRepublic: What technical requirements do you need to define for a CMS?
Meugniot: Before you can successfully evaluate CMS products, you need to carefully and equally consider technical requirements that address critical business problems, content management and distribution needs, integration with existing systems, and support infrastructures.
I typically look at a host of technical requirements, including:
- Specific content management and delivery functions.
- Content migration, which is often the most overlooked requirement.
- Existing systems and platforms.
- Internal skill sets and existing technology investments.
- Scalability, especially for Internet sites with traditionally high or seasonal traffic.
- Security of intellectual property or content, which are often a company’s primary assets.
- Reusability, because once a site is launched, new requirements and modifications are predictably right around the corner for even the most well-planned solutions.
- Expandability, since content management applications are generally one of many in an overall architecture. They should allow integration of third-party applications and adhere to industry standards.
- All third-party systems that require architecture integration.
- Protocols and integration methods (such as Web Services).
- Reliability, especially if you are considering a reduction in your technical-support capability.
- Autonomy, as content management functions (such as content entry) should operate independently of your Web delivery functions (such as serving Web requests).
- Bandwidth and user load, as they provide context for sizing and capacity planning.
- Performance requirements that can help a CIO measure the success of an implementation, especially when other quantifiable metrics do not apply (such as product sales volumes or subscription growth).
CMS series: Part 4
This is the fourth part in a five-article series on implementing a content management system. Click on the links below if you’re interested in catching up on the previous installments:
- "CMS strategy: Don't put the cart before the horse"
- "Consider these factors when determining ROI on a CMS"
- "Defining CMS content requirements"
What questions to ask and to whom
TechRepublic: To whom do you talk when you're trying to gather technical requirements?
Meugniot: When defining technical requirements, it is important to build a complete perspective. I normally facilitate requirements-gathering sessions with CIOs, DBAs, developers, system administrators, HTML developers, project managers, support staff, and operations personnel. But technical resources aren’t only limited to the IT department; you might also need to track down the tech people distributed across the marketing, customer support, sales, and accounting departments.
TechRepublic: What questions do you ask them?
Meugniot: In most cases, I will start by asking technology stakeholders to describe their existing systems and assets in the context of the new solution. Example questions include:
- Describe your existing high-level architecture components.
- How do you currently diagnose system problems?
- Describe the roles and responsibilities of your technical staff.
- Describe your Internet systems and capabilities.
- Do you have an application server standard?
- Do you have a defined security policy?
- Is it common practice to perform stress-testing on your Web architecture(s)?
Once I’ve audited their existing systems and processes, I ask questions like:
- Is it important to leverage the recent investment of your J2EE application server?
- Do you wish to migrate your existing data to the new solution?
- How do you feel about using your current LDAP server to manage your internal users and security?
Then I try to decompose the emerging software architecture by asking questions like:
- Do you prefer to move away from your current sockets-based approach of communicating with disparate systems by leveraging XML and SOAP?
- Is there a defined specification or interface to integrate with your product database?
- How do you feel about real-time publishing vs. batch?
- What database(s) do you prefer to use and why?
Determining what users and stakeholders really need
TechRepublic: The most difficult part of gathering requirements isn’t the act of recording what users want; it is the exploratory process of helping your users figure out what they actually want. Do you have any interviewing strategies for getting people to tell you what they really need?
Meugniot: Experience and examples are the keys. When I interview users and other stakeholders, I always leverage my experiences of building similar content management systems and provide examples as often as possible. As most CIOs know, content management is more than just software. It is a delicate web of people, business processes, and technologies that come together to form meaningful systems. By drawing on my experiences in building complex content management solutions, I can provide my clients with options and proven results.
Examples help clients navigate new territory successfully. I can provide relevant examples of features, functionality, architectures, products, and processes that help clients to build their vision and solution. I provide the subject matter expertise and the framework; they provide the resources and the substantive detail.
In terms of tips or tricks for getting people to tell me what they really need, it all comes down to experience and a good ear. Listening to clients and understanding their needs is crucial. Anyone can install content management software; it takes an experienced guide to construct a successful business solution.
Watch out for these pitfalls
TechRepublic: What are the common roadblocks or barriers you commonly meet in trying to capture the requirements in an organization? How do you get around these barriers?
Meugniot: Consensus building is not easy. But driving requirements and building consensus are just part of the process. Clients have a business to run and frequently have little time or few dedicated resources to design, develop, or manage new content management solutions. Although their participation is essential, it is up to you to make their involvement as productive as possible. Sometimes, the onus is on you to help a marketer understand why they need to sift through 1,000 images to select those best suited to represent products displayed on a particular page. A “nice to have” will often translate into increased cost and little overall impact; that’s why it is just “nice.” You must help your clients to understand the difference.
Still to come: Forming a CMS team
Putting together a talented, skilled CMS team is the last step in a CMS implementation effort, something I'll cover in the next and final installment in this series. Stay tuned to for tips and guidance on making the best staffing decisions for the project.