CMS Product Selection Process with Templates

The number one problem with implementing most content management systems is the desire to go shopping for products before you sit down and gather your requirements as to what you need. This video segment is defines the proper process to go through and select a product for your content management implementation.

People are sold on flashy demonstrations, and they’re not taking that product into context of how they’re going to be using it in their own organization.  And by the time they get it implemented it’s too late.  It doesn’t really meet their needs; there’s a large backlash from the user community, and the system ultimately is going to fail.  Now this could be applicable to any type of CMS implementation whether it’s a Web content management, component content management, document management, mobile content management, the same process applies. I’m going to be using examples for Web content management implementation, but you can take the general flow and the templates that are going to be provided and use those in your own context.

When you’re starting out, the first thing you need to do is ensure that you’ve got requirements. It seems like a simple statement, but it actually takes a lot of effort to ensure that we don’t slip down that road of jumping in and doing vendor demos. The main reason why people jump into this is because there’s a bit of a lack of knowledge as to what’s available. They want to do some investigation, fair enough, investigation’s great, but don’t go so far as to getting those demos. Stop at doing your investigation, and ensure that you have developed your requirements before you go that far.

Now when you develop your requirements, there should be a direct tie of your requirements back to a business need. And if you can’t tie that back to a business need, then you should question whether or not you actually need it.

Let’s talk about the overall process. The process starts, as I indicated, with the definition of what the business requirements are. This will be accomplished by executing stakeholder interviews. I have another video on fifty questions you should ask before implementing a WCM solution. Take a look at that; it should give you some ideas – even if you’re not implementing a WCM; it will be beneficial for you to take a look at that.

The next part of that – after you’ve got your business requirements is to translate those into technical requirements. And why do we need to translate them? Well, we want to keep the business requirements in terms that the business user can understand, but in many circumstances, they are not applicable to making a selection. So we need to go through that translation; I’ll be describing that in a second. After we’ve got our technical requirements, we can do a high-level industry analysis, and this is where you go out to different vendors’ sites and – and research what it is that their product can do. I would highly recommend the vendor analysis reports from the Real Story Group. They are several thousand dollars, and many smaller implementations may not be able to afford it, but if you can, very, very good resource to go after, and they’re kept up to date, so that’s something to consider.

When you’ve done your industry analysis, you know who all the players are, then you want to weed them down to ideally about three different vendors, maximum four, try not to go beyond four vendors. Then you’re going to develop a demonstration script. You don’t want the vendors to give their standard script, because they’re all going to be talking about different things, and there’s going to be no way for you to evaluate one against the other, so you want them all to answer the same questions, ideally in the same order, so you can apply the same evaluation against all of them. And then, once you have that, evaluation’s all done, you can then assess those vendors, compare them, and then ultimately make a decision.

So let’s talk a little bit about each one of these steps in a little bit more detail. Let’s talk about the business requirements. When you’re assessing the business requirements, the first thing you want to look at is what the current issues or pain points are. Are there particular processes that are prone to errors? Are there resources who aren’t using their time adequately or are bogged down with these very manual tasks where there’s not a lot of value? Is there an inability to react to the market? So, if something happens, marketing department wants to get something out on the website quickly, are they finding it difficult; are they going through a bottleneck, those types of things. After you’ve had a chance to talk about what the pain points are, then analyze what your current content needs are. This is where we talk about what is the content, how much content do you have? Who needs to author it; what is the structure of the content; what is the way in which it needs to be presented; are there particular business rules around that? Again, when you’re looking at these business requirements, go back; have a look at that video, fifty questions to ask when implementing a WCM; that’ll give you some ideas.

Once you’ve looked at your current needs, then you start to look at the future. Break up your future needs into short-term and longer-term needs, because your longer-term needs are going to be far more difficult for you to really define. But we should have an ability to define what our short-term needs are. What are our particular marketing needs? Do we have any estimates of how long we’re going to be or how much we’re going to be growing? Things like that, and that will give a bit of an idea as to, you know, what we need the system to do currently, and potentially where we might be looking for a fit for us in the future.

Now, as I indicated, we need to take those business requirements and translate those into technical requirements. I have a template that’s provided in this blog post, so have a look at the template and use that. In some degree it requires a bit of knowledge of content management systems, so this is where your research going to take effect. You’re going to want to see how certain products are accomplishing certain issues and then be able to translate that into terminology, which is going to allow you to develop your demo script. When you’re coming up with your technical requirements, try to use words that’ll indicate prioritization like the system must do this, or the system should do this, a little bit lighter, which means it’s giving a little bit of, , leeway. If you’re saying a system must do it, it’s kind of like, “If it doesn’t do that, it’s not going to make the shortlist.” The system should – allows you to say, “OK, it doesn’t do that, but it does something that’s comparable,” and – and lastly, another term to use is, you know, “The system should ideally,” which is a little bit more lenient; we’re saying, “OK, this is kind of what we’d like to have,” but we’re open to – to some other options.

When we develop the vendor demo script, there’s a template for this; have a look at the template; it’ll help you develop your own – again, just to reiterate, try to keep the number of vendors to about three, four at the max. Don’t be surprised if some of the vendors aren’t willing to go through the demo – a lot of open source companies simply don’t demo their product, lower-end systems as well; they just simply don’t have the revenue to spend time giving demos to everybody, so you may have to either rely on videos that particular vendor will put out, or you might have to download the software if they had provide a trial, and try it yourself. Go through the script yourself as if you were the vendor.

Now when you’re writing up your demo script, you’re going to use words like ‘demonstrate’, or describe, or provide information. If you use the word demonstrate, that indicates that you want the vendor to actually show you how to do that. If you use a word like ‘describe’, you’re allowing them to verbally and maybe with some pointers on the software, how something might be accomplished. If you use the term ‘provide information’, what you’re asking for is, for them to send you, maybe a PDF, information how this could be configured. They’re not going to do that in the demo; they’re going to provide some information to you or point you to where that information can be found.

Now the number of questions should be kept under forty. I do not recommend a demo go over two hours. Two hours is still about the right amount of time. If you have any more than forty questions, you’re not going to get through it. So ideally, target for about twenty to thirty questions, and go over the script with the vendors, so they have a good understanding of what those questions mean to you, so they can make sure they put them in the proper context. That might even entail providing some additional content that they could go through the demo script with – to put it more into your context.

I’ve laid out a couple of the different assets you’re going to be looking for. And I’ve provided templates for two of them, but let me just give you an example of how they flow together. Starting with our business needs, let’s say that one of the business needs is that the business doesn’t have the resources to manage users and their accounts, and so, that’s a concern of theirs. You would translate that into a technical requirement by saying, “The system must be able to integrate with your existing corporate LDAP” so that the particular department or division that’s implementing the system doesn’t have to worry about it; it’s simply going to leverage what currently exists in your organization. So that’s the technical requirement, and that’s the way that you make that translation for them. And some business users may understand what LDAP is; many will not, so that’s why we make that separation. Then when it comes to the vendor demo script, you would say something like, “Describe,” because obviously you’re not going to get them to demonstrate, “Describe how your system can integrate with a corporate LDAP system.” Now you may want them to describe, you may just say, “Provide information,” or something like that on that particular point, but that’s an idea how you take a particular business need, translate that into technical requirements, and ensure that it’s covered off on your vendor demo script, so everything that you’re watching in your vendor demo script must be tied back to a business need. Again, if it’s not tied to a business need, then you have to question why you have it or need it or if you’ve missed a business need. That’s very likely as well; you can go back and add on business needs later.

Now when it comes to the vendor evaluations, have a look at the template that I’m providing. Each question in the list has a weighting from 1 to 5, and each vendor’s going to get a score for each question between 0 and 5. Zero being that it doesn’t solve that particular issue at all. Five being, you know, it’s the best of – of the group. Within each one of those questions, you’ll see in the template, there’s a little spot for you to jot some notes about each one of the vendor – put notes in which justify the score that you’ve given that particular vendor, OK. That’s going to help you reinforce later on as to, you know, why that score was chosen over another, because you are going to have to go through justification when we get into evaluations we’ll discuss that in just a second. Now, at the end of the – the demo, it’s nice if you can have a little bit of time for the vendor to cover off on some points that weren’t covered in your demo script; they might be unique to the product, a value add, so allow them a little bit of time to – to show those.

Now, when it comes time, you’re finished your demos, and you want to make a selection. The first thing, when you’re going through those evaluations, get everybody on their team to carry out an evaluation, and get them to do so independently. Then bring every back together and compare your scores. Now the first thing you’re going to want to compare are the question weightings. I don’t think this is important to set up ahead of time. I think it’s good for people to have gone through the demos, and then they’re a little bit more informed to assign those weightings. But it is important that you, globally, across everybody in your team, determine what those weightings are going to be, and then assure that they’re normalized across all of the spreadsheets. Once you’ve done that, then you can take everybody’s scores and average out the scores for the vendors. Sit down with everybody, and ask for general impressions. What you will find, more times than not, is that the general impressions of the group will reflect the overall score.

Now the score’s only a guide. If you’re seeing that the general impressions of the group do not reflect the score, then you might want to go back and take a look at the weightings, why is it that things are turning out different. It’s likely to be within the weightings that we’ve got too much value placed on one, and not another, so you can have this time to go back and re-evaluate. The scores are a bottom-up way to do an analysis, and the general impression is kind of like a top-down, and you’re looking for consensus between those two mechanisms. Then when you’re going through those scores, if there’s a difference of opinion in scores, somebody gave a 3; somebody gave a 5; that’s where your notes come in, “Well, I decide to give this guy a 5 versus a 3 because of this particular point – ”; gain some consensus amongst the group. What this is going to help you do is gain consensus amongst the group and then have something to be able to justify your decision, because other people are going to be questioning why this particular decision was made.

So that’s the process, and I think you’ll be surprised as to how easy it is to gain consensus by going through a very thorough and justifiable process like that. I’d be really interested to hear your comments, not only on this process, the templates that are provided, but particularly if you’ve gone through this process, and you have some experiences you’d like to share with us, please add some comments, I’d like to hear from you.