Chapter 15

Determine System Requirements


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

Does this Apply?

All of this only applies if you know you’ll be selecting a content management system (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.


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:

  1. You have three kids, so you need a backseat

  2. You live out in the country, in South Dakota, on a dirt road, so you need four-wheel drive

  3. 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 trying to hook a horse trailer up to it.

Once you get past the requirements you move on to less tangible factors – how does the vehicle make you feel? Like we noted, you could buy a Ford F-350 or a Chevy Tahoe XL. Either would fulfill your requirements, but they certainly have a different feel to them. The pickup might make you feel like a general contractor, while the SUV might make you feel like a parent hauling kids to a soccer game. That’s an entirely different set of factors.

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

  1. Hard: these are non-negotiable (“must-have”)

  2. 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:

  1. Features: specific capabilities the software claims to have

  2. Infrastructure: how the software exists inside your organization’s technical environment

  3. Financial: how the software is priced, both in amount and structure

  4. 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 area, and we’ll give some examples of both hard and soft requirements with each.

Features: What does it do?

Content management systems have a wide range of features. (Don’t look now, but Deane may have written an entire book about this). Below, we’ll try to put some shape around some of the common features we see customers need (or think they need), but understand that this is far from an exhaustive list.

  • Content Modeling: This is the ability for a CMS to accurately represent a logical model of your content. This is 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 the last chapter, 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.

When determining requirements for your new system, it pays to be flexible. Concentrate on the final goal you want to achieve. For instance:

  • 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?

Additionally, that “less good” example only works well if you’ve done A/B testing before and have significant experience with it. Too many times, buyers are just repeating things they’ve heard about but never actually done and which they’re completely unable to accurately evaluate.

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.

However, in the real world, there are lots of other considerations to take into account. And, sadly, sometimes a great system with all the features you want just doesn’t work for other reasons – it costs too much, or is written on the wrong technology stack, or doesn’t have a large enough partner network. So always keep in mind that the featureset a system offers is just one part of a larger puzzle.

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 software sales assume that the software will run elsewhere, managed by someone not in their organization.

Here’s a key point: you need to understand what your organization expects and requires. Specifically:

  • 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 the 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 software.

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?

Here are some examples of how these requirements might play out:

  • Mark works for a small non-profit. They need a marketing site to get their message across, but 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, and he doesn’t know a database server from an ice cream sandwich. All he has has a company credit card, and has been told to get a website up next week.

  • Jennifer works for a global financial services company with 8,000 employees worldwide. She is working with a external marketing agency on a campaign microsite. The organization works with high net-worth individuals, and it is incredibly concerned about security for their clients. IT requires everything to be hosted in their in-house data-center. They have 1,500 people in IT, including several hundred database administrators and developers. Their web servers are Red Hat Linux, backed by Oracle.

  • 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 on a service like Microsoft Azure. They do have some development staff in-house that are skilled in ASP.NET, so they need a C#-based system they can program internally and then deploy to the cloud.

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 Red Hat and Oracle.

  • Sam can host it anywhere (remember, the IT department doesn’t care), but it’s going need to built by the organization’s developers, so a .NET-based system is a requirement.

For people having to use the system to achieve a business result, this can all be annoying.

To a marketer, 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:

  1. Who is going to build the website, and what language do they know?

  2. Who is going to host the website, and what technology stacks can they support?

In a perfect world you have no restrictions. And this is possible – you might be working with an external partner who can work on any language, and hosting in a cloud environment that supports any technology stack.

Fingers crossed.

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; vendors will often use the word "solution" to represent 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, using a five-year timespan.

  • CMS X is an “unattended” software as a service (SaaS) system, that you can subscribe to with a credit card. It costs $99/month. Over five years, this system will cost you about $6,000.

  • CMS Y charges $30,000 up-front, then 20% of this per year after the first (a model known as “enterprise software subscription”). Math tells us that this will cost you $54,000 over five years.

  • CMS Z charges $6,000 per month, and they require a $10,000 “onboarding fee.” In addition, you have to provide your own hosting, and that separate hosting vendor will be another $1,200 per month. More math gives us a TCO of $442,000 over five years.

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 money , expense categorization , 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.

We may have stolen our own thunder here, but the second part of pricing systems after figuring out the actual TCO is how the deal is structured, meaning when do you have to pay, and what is included?

For years, the predominant pricing model was that of CMS Y: a one-time purchase cost, with a percentage of that cost every year thereafter. This is known as “software subscription.” Paying this annual fee might be required to continue using the software or it might just enable some added value – such as support, upgrades, and the right to use the software for free on non-production environments (like test servers). The annual percentage varied, but averaged 20%.

Sometime in the last five years, the “pure subscription” model became more dominant. This is where you pay a set amount per month to use the software, with no variance in first-year and subsequent year costs. Vendors and customers seem to prefer this model as the enterprise moves to "the cloud" and idea of actually owning software falls out of vogue. Many customers were so accustomed to paying 20% subscription that they never really owned anything in the traditional sense anyway, and lower up-front costs hopefully equalizes outlays with roughly the same TCO over time.

Finally, when considering subscription pricing, you need some idea of when you’re going to have to start paying for the software. When does that first month commence?

A full, ground-up web rebuild like the one we’re discussing in this book can take 8-10 months. If you select your CMS early in that process, and agree to buy it, 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?

You often need to have to license software to start developing with it, so you can’t start building until you pay. With other software, this isn’t the case. You only need to start paying once you deploy. This can make the difference of tens of thousands of dollars if you have to start paying for six months of usage before you can actually use the software to derive any practical benefit.

Some systems have “on-ramp” pricing, where you pay a lower fee until you launch to production, but this is rare.

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? Here are a few reasons why larger organizations tend toward commercial CMS over open-source (note that all of these risk starting a Holy War with members of various communities, so take it all with a grain of salt):

  • 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. Sophisticated marketing organizations might be expecting a higher level of functionality than is available in the open-source market.

  • 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 add-ons provided by the community for advanced functionality. This can bring some problems, like upgrade compatibility ("we can’t upgrade because Plug-In X doesn’t work with the new version!") and security issues (install a dozen plug-ins, and now you have a CMS effectively built by 13 different organizations).

  • For better or worse, many organizations want a single vendor to stand behind any product they use. Organizations are looking for the proverbial “one neck to choke” if something goes wrong. If they use an external partner to develop, 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 to commercial, "enterprise-level" hosting around open-source products , 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:

  • Community Support: This is in the form of support forms hosted by the vendor, or in other locations, such as the community-driven site Stack Overflow. When you have a problem, it’s very helpful to be able to reach out to someone else for a solution.

  • Documentation: Blog posts, screencast videos, and sample code can be enormously helpful to get up-to-speed on a platform or some specific aspect of it. Some systems (especially open-source systems) are so pervasive, you can simply Google an error message and usually find a solution.

  • Partner Networks: For most software, there is a network of companies providing professional services around it. These are often in the form of formal “partner networks” that are affiliated with a specific system, or just a loose professional network of people who are well-known in that community.

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 requirement 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.


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.