Chapter 15

Determine System Requirements

Summary

At this stage, you have enough information to draw up requirements for what you need in a content management system (CMS).

Does This Apply?

This only applies if you know you’ll be selecting a CMS. You might already have one, or one might have already been selected for you. If so, then this is something you don’t need to worry about.

However, if you’re going to be using a CMS and don’t already have one, you’ll need to concern yourself with everything in this chapter.

Narrative

Purchasing decisions are based on two things: your actual requirements and your gut feeling. Marketers play on both of these things.

If you’re looking for a vehicle, you might have some tangible requirements for it:

• You have three kids, so you need a backseat.
• You live out in the country, in South Dakota, on a dirt road, so you need four-wheel drive.
• You have two horses, and you need to pull them around in a trailer.

Clearly, with these three requirements, we’ve taken the entire domain of available vehicles and cut them down drastically. You need a pickup or maybe a full-size SUV with a minimum towing capacity.

To be fair, a lot of options still exist in that space, but if you go to the car dealer and come home in a Porsche 911 you’re going to be sorely disappointed the first time you try to hook a horse trailer up to it.

But then, there’s that little thing called a gut feeling. How does the vehicle make you feel? A pickup might make you feel like a general contractor, while an SUV might make you feel like a parent hauling kids to a soccer game.

They may not be tangible, but those feelings still matter. Thus enters the grey area of prioritizing requirements.

Thus enters the grey area of prioritizing requirements.

System Requirements in a Nutshell

Despite the word itself, requirements aren’t always required. When we talk about a content management system, requirements are simply elements of a software platform that exist on a sliding scale of desirability. We might roughly segregate them into:

• Hard: these are non-negotiable (“must-have”)
• Soft: these are negotiable, and some are more important than others (“nice-to-have”)

When it comes to buying software, these requirements can fall into all sorts of subject areas:

• Features: specific capabilities the software claims to have
• Infrastructure: how the software exists inside your organization’s technical environment
• Financial: how the software is priced, both in amount and structure
• Ecosystem: the organizations and services that exist around the software 

This means your requirements for software are a combination of two axes: your needs and how elastic those needs are.

Let’s talk about each subject area, with some examples of both hard and soft requirements with each.

Features: What Does It Do?

Content management systems have a wide range of features. There are some features customers commonly need:

• Content Modeling: This is the ability for a CMS to accurately represent a logical model of your content – essentially, the technical representation of the model we created in Chapter 11: Model Your Content, and it’s more important in some situations than others. A small campaign site might not need much beyond a generic “page,” while other sites might have detailed, intricate models.

• Editorial Tools: These are the tools editors are given to actually manage content. Features like workflow, approvals, preview, collaboration, etc. These are tools that let you do the “management” of content management.
• Security Tools: This allows for the management of users, their organization into groups, and the assignment of permissions. Some systems are simple enough to be binary – you’re either authenticated or not – while others allow for highly granular control over specific permissions for what might be hundreds or thousands of users.
• Publishing Tools: These are the features and frameworks that allow you to broadcast content into a delivery channel somewhere. For most systems, this is a templating system that allows you – or your developers – to generate HTML that can be delivered to a browser. However, a CMS can push content into other channels, like social media or mobile devices.
• Media Management: These are the features around the management of rich media files, like images and documents. Some systems just allow you to manage a directory of files on the server, while others allow detailed modeling and management of media files just like other content.
• Integrations: As we discussed at length in Chapter 14: Know Your Integrations, these are the hooks that allow your CMS to communicate with other systems, as well as the library of other systems that have packaged integrations with your CMS.
• Marketing and Optimization Tools: These tools allow for the optimization of content by doing things like personalizing content for specific visitors, showing different variations of content to see which one performs better, and tracking visitors to develop a comprehensive profile of them.

When determining what features you need, it’s important to take a critical look at your organization, your plans, and your capabilities. Lots of projects have bitten off more than they could chew and purchased functionality they didn’t have any chance to use.

While it’s tempting to find a system that’s loaded to the gills because “we just might need this feature someday!” know that every feature costs money, in terms of both upfront outlay, and increased support, training, implementation, and distraction. Don’t take your eye off the ball.

Instead of focusing on sheer numbers of features, focus more on the goals you want to achieve, and be flexible. For example:

• Good: We want to create multiple versions of content to see which one is more effective.

• Less Good: We want multivariate testing that allows us to visually compare unlimited versions, specify the percentage of visitors exposed, and track click-throughs to a conversion page.

The “less good” example is very specific. If a system fails one part of that – for instance, if it can’t offer visual comparison – then does it fail the whole requirement?

In a perfect world, our CMS selection story would begin and end here – we would simply pick the system that had the features we needed, and everything would be wonderful. But will this play nicely within your existing infrastructure?

Infrastructure: Who Is Building, and Who Is Hosting?

Software has to exist and execute somewhere – on some computer, in some data center, in some country, managed by some people. Traditionally, we’ve called this “hosting” or “web hosting.” Some combination of infrastructure – servers, routers, network access, etc. – serves as the “host” for software you could connect to.

With the advent of the cloud, the questions around hosting have gotten hazier. Lots of people think software just exists “out there” somewhere. So long as you can connect to the Internet, you’re good. The cloud has become hosting by another name.

Occasionally, an organization requires control of software’s hosting – the software needs to run on computers they control. We still see this in the financial services and health care markets a bit, over privacy and security concerns. But cloud hosting has advanced to the point where most CMS sales teams assume that the software will run elsewhere, managed by someone not in their organization.

Here’s really what you need to know:

• Who in your organization can make this decision, and what are their preferences and reasoning?
• Do they require control of the software, or do they specifically not want to come anywhere near it?

In addition to hosting, software is built on some “stack” of technologies, from the operating system outward. There’s software that runs on Linux, software that runs on Windows, and – increasingly – software that runs on both. Beyond the operating system, software is written in a specific language – Java, PHP, and C# are common – and uses a specific database software11We’ll talk more about all of this – hosting itself, as well as the technological stack – in Chapter 17: Plan for Hosting.Close.

To what extent does your organization want or need to program against or manipulate this technology stack? Are you going to develop and program the website in-house? Or are you going to work with an external partner?

And if your organization is hosting the software in-house (as opposed to “the cloud”), are they prepared to support all the separate layers of the technology stack? Do they have servers running the correct operating system? Do they have a licensed copy of the database server?

This can really get into the weeds, so let’s illustrate with a few examples of how these requirements might play out:

• Mark works for a small non-profit that needs a marketing site. They only have nine employees, and no IT staff. They use Google Apps and everyone works on their own laptop. Mark literally cannot host anything: all he has is a company credit card, and a task to get a website up next week.
• Jennifer works for a global financial services company. She works with a marketing agency on a campaign microsite. The organization is incredibly concerned about security for their clients. IT — a 1,500 person department that includes several hundred database administrators and developers — requires everything to be hosted in their in-house data-center.

• Sam works for a regional banking chain. They have an extensive IT staff, but that staff is busy running frontline business applications. Since the public website is mainly marketing functionality, they’re fine with it being hosted with the CMS vendor.

Each example provides various restrictions:

• Mark is self-contained. He can’t (1) host, or (2) develop. So, those two restrictions limit his selection to simple, unattended, site-building systems like Squarespace or Wix.
• Jennifer doesn’t have development restrictions (we assume her marketing firm is developing the site), but it’s going to need to be hosted in-house, so it requires a system that runs on compatible in-house servers.
• Sam can host it anywhere (remember, the IT department doesn’t care), but it’s going to need to be built by the organization’s developers, so it needs to be based in the same programming language.

For people having to use the system to achieve a business result, this can all be annoying. To most marketers, for example, the details don’t seem relevant to the effectiveness of the final product. But, unfortunately, these have to be accounted for sooner rather than later, because finding out about a hard restriction down the road (“um … we don’t know that language”) can be a real problem.

Find the people in your organization with authority over your IT infrastructure and ask:

• Who is going to build the website, and what language do they know?
• Who is going to host the website, and what technology stacks can they support?

Then you’ll be closer to your solution. Now, how much are you willing to pay?

Pricing: How Much and ... How?

Pricing of CMS systems differs wildly in both the obvious – how much does it cost? – and the less obvious – how is that cost structured? Given the differences, the only real way to examine costs is to consider a metric called Total Cost of Ownership, or TCO. 

TCO measures the total cost of a solution over a specific, named timespan. There are a few things from that sentence we need to unpack:

• Total: meaning not just the cost of the software itself, but the cost of the services and infrastructure surrounding it, no matter to whom the check is being written (or if it’s an internal cost).
• Solution: which usually means software and services. The CMS, any add-ons, and the cost of design and implementation, for example. Vendors will often use the word “solution” to signify that they’re selling those things together.
• Specific, named timespan: which means from the day you start paying to some point in the future, which is used to estimate and equalize costs.

Here are a few examples of software cases with associated hosting, using a five-year timespan:

Two things to note there – First, these are simple calculations. The real world is messier, and might involve things like the time-value properties of money22The “time value” of money means that money you have now is worth more than money you’ll have in the future. So, a $5,000 expense 10 years from now is more affordable than the same expense today, because inflation will cause $5,000 to be effectively worth less in 10 years.Close, expense categorization33In the accounting practices of many organizations, there’s a difference between a one-time “capital expense” and an ongoing “operating expense.” Organizations might have differing amounts of money available for each.Close, other contractors you might engage with, and vendor claims that you will actually save money on other aspects of your environment over time.

Second, you can begin to see why you have to name a specific timespan. The three systems above have drastically different pricing structures, and there’s no way to compare them without some reference to how long you’re going to pay for them. CMSs X and Z are “rented” for time periods, while CMS Y seems to be purchased with a maintenance fee. They just have no comparison value outside of a time period. Additionally, note that CMS Y is front-loaded, with over half of its expense coming in year one. It looks more attractive the longer you use it. Changing your timespan from three to five years changes the financial picture of that system.

How CMS Pricing Models Are Structured

For years, the predominant pricing model was a one-time purchase cost, with a percentage of that cost every year thereafter. This is known as “software subscription,” represented by CMS Y in our previous example. Paying this annual fee might be required to continue using the software or it might just enable some added value – such as support, upgrades, or free copies of the software for test servers. Recently, the model has shifted slightly to remove the one-time purchase cost and instead focus solely on a monthly subscription.

The major question with subscription pricing is when you’re going to start paying for software. When does that first month commence? A full, ground-up web rebuild like the one we’re outlining in this book can take eight to ten months. If you select your CMS early in that process, simple logic tells us that the vendor wants you to start paying as soon as possible (a pretty safe rule: vendors like revenue).

However, do you need the software that early? Sometimes … yes.

You often need a license to start developing with the software, so you can’t start building until you pay. If you can find software that delays costs until you deploy, or after a set development time, this can make the difference of tens of thousands of dollars.

Should You Even Pay for a CMS?

All of the above assume you’re going to buy a commercial CMS, which isn’t required. There are hundreds of open-source CMSs available, in varying degrees of quality and polish. In fact, CMS is probably one of the most popular genres for open-source development.

The open-source market varies wildly in scope and quality. Some systems that have reached a massive level of adoption (Drupal and WordPress, for example), but there are hundreds of others with little adoption, for which support and documentation is scarce.

With attractive options available at no cost, why buy a commercial CMS at all?

• Marketing functionality: Open-source CMSs are generally more concerned with the core management of content, and less concerned with higher-level marketing functionality. Few open-source systems have marketing optimization features like personalization or A/B testing built into the core of the product, and relatively few of them integrate with the larger marketing automation suites.
• Core functionality, rather than plugins: Open-source CMSs are often comprised largely of add-ons or plug-ins, given the distributed nature of the communities that develop them. It’s quite common to keep the core of an open-source CMS very lightweight, then depend on addons provided by the community for advanced functionality. This can bring some problems, like upgrade compatibility and security issues.
• Single vendor “security”: For better or worse, many organizations want a single vendor to stand behind any product they use. If they use an external partner to develop their open source solution, they can still get this, but if not, then they have to depend on a sometimes-amorphous community to provide unpaid support. Certainly, several companies have sprung up to provide commercial, “enterprise-level” hosting around open-source products44The most obvious example here is Acquia, which provides a hosting and value-added infrastructure around Drupal, which is open-source.Close, but then you might end up paying just as much as you would pay to a commercial vendor.

Your mileage may vary, of course, and for many organizations, open-source works wonderfully and the lack of a license is simply a bonus.

Ecosystem: It's Better with Friends

Oftentimes, an organization decides to build their own CMS, rather than purchase one, or use an available open-source option. They figure they won’t have to pay a license fee, they’ll know it intimately, and they’ll craft it to their specific requirements.

Sometimes this works out. Mostly, it doesn’t.

One of the biggest problems with building your own CMS is simply that you’re the only one who uses it. You are a small island in a vast ocean of challenges and problems. When you need a solution, you have only yourself to lean on. There’s no one out there coming to your rescue.

“Ecosystem” is a handy term for the entire environment of other people and organizations who are experts in a software platform. This is both the vendor who may have built the software, and the entire universe of people using the software. An ecosystem manifests itself in different ways — through community support, robust documentation, and a rich partner network.

While the example of building your own software clearly exhibits a lack of everything above, you can have the same problem with software you purchase or download. Don’t assume that because the system is publicly available – either open-source or paid – there’s a thriving ecosystem around it. Many open-source systems don’t have wide adoption, or are getting quite old and are no longer being actively developed. Additionally, some commercial vendors are quite small and don’t have much of a third-party partner network to speak of.

The ecosystem needs to be evaluated like any other feature. Some are better than others, and unless you have a deeply-staffed internal department, or an external partner with scads of experience that you expect to be working with for many years, you will need the benefits of an ecosystem at one point or another.

Inputs and Outputs

The input into this process is a well-informed team with a plan for what the completed website will need to do. You need to know what your editors want, and some idea of how they’ll interact with the system. You also need to get at least some idea of where your organization stands on budget, and if you have hosting and/or development constraints that would require a specific technology stack.

The Big Picture

You need to put some thought into this before you start looking for a CMS. And to have productive conversations about it, you need to have done some planning for your future web presence. It’s going to be hard to define requirements if you don’t even know what you’re building. Your plans don’t have to be perfect, but you need some framework of needs before you can decide how to solve them.

Staffing

You can do this yourself, but you might want to employ a “selection consultant” for help with this. There are consultants who work with organizations on just this problem – helping them match their needs to a software platform. The first stage of a good consulting exercise is what we discussed in this chapter: determining your needs and how these might overlay on the current state of the market. In later chapters, we’ll talk about the other parts of this engagement, writing RFPs and managing the process itself.

Resources

Articles

• "How to Categorize the Web CMS Marketplace ", CMSWire, by Tony Byrne
• "Real Story: Honing in on the Right Marketplace", Real Story Group, by Jarrod Gingras
• "10 Things To Consider When Choosing The Perfect CMS", Smashing Magazine, by Paul Boag

Books

• Web Content Management: Systems, Features, and Best Practices by Deane Barker