A client with several years of CMS experience recently she pointed out that she thought that CMS products we were going through a revolution. I had to agree, over the last couple of years we have seen major changes in the CMS world. Some of the facets of the “revolution” include:

  • old CMS products we grew to love and hate have been acquired, all the large independent players (Vignette, Stellent, Interwoven) have now been acquired, opening the way for new entrants into the market
  • online communities are more important than vendor viability. Proprietary vendors now realising the importance of developing communities, encouring their products to be discussed openly online warts and all! This kind of information wasn’t readily available thanks to vendors wanting to control “the message”.
  • open source and SaaS are now being seriously considered alongside purchasing licenses for proprietary systems. Historically decisions about Open Source were made at the outset, rather than being largely irrelevant.
  • ease of use is king. You no longer have to go on several days of training to grapple with clunky interfaces in order to manage your content, some content management functions can be performed without any training at all!
  • You get more for less. Prices for licensed software have come down providing CMS buyers with more functionality that ever before for less.
  • Downloading and try software. Some vendors allow you to try their software for free, and not demand several days consultancy services to come in and install the system.
  • the rise of social media, means that products are fundamentally being rearchitected from where the content management is performed on the back end as well on the front end.

I’m sure there are more aspects to the revolution that I’ve missed that you will come up with. I ran the idea of a CMS revolution past Tony Byrne who partly agreed with me! So what are your thoughts, are we in a CMS revolution or is CMS software as bad as ever?

During a CMS selection project someone said that he thought the CMS systems he had seen demonstrated appeared to be the same! The reasons for this were:

  • They performed the same functions e.g. content publishing, versioning, workflow, searching etc.
  • They used similar ter`minology to refer to the products e.g. Content Server, Deliver server, modules etc.
  • The vendors presentations were performed in much the same way, e.g. complany profile, client list, product demos

I agree, that CMS demos can be a bit of  a blur especially when you have a few on the same day! Most clients want to focus on content, usability, and their audiences, and they do not want a CMS selection project to be about “technology”. CMS selection teams should consist of staff from different departments and skillsets e.g. IT, finance, Marketing, Press and Communication, and it is easy for them to become overwhelmed with the amount of information they need to make sense of.

With an estimated 4000 CMS systems in the world there is a vast amount of choice out there. CMSWatch covers around 40 products as part of their WCM report, so the evidence suggests that they are not the same! Even on a shortlist of 2 vendors they usually differ in their :

  • strengths and weaknesses
  • licenses models,
  • costs (and discounts),
  • implementation partners,
  • customers,
  • sizes and types of projects,
  • architecture etc.

So next time anyone in your team says “but they are all the same!” whack them over the head with this post!

See Also

5 Biggest Mistakes in CMS Selection

During a recent recent CMS vendor selection exericise I took a step back and realised how much time and effort was being spent on getting a firm price on the cost of each CMS product. CMS licensing is complicated as it depends on so many variables e.g. number of users, sites, servers, cpu’s, environments etc.  CMSWire posted on twitter

cmswire_cms_licensing

To help me write this article I enlisted the help of the folks on twitter, so why is CMS licensing so complicated?

Twitter feedback

Jon Marks (@mcBoof)  has written an excellent article titled When CMS Licensing Shafts Architecture , where comprises have to be made to the CMS solution architecture due to how products are licensed. Jon’s article states that a CMS may be licensed :

  • A per site or domain cost – the vendor should clarify about what constitutes a “site”
  • A per machine / CPU cost – some vendors which will charge extra for each server a particular product is deployed.
  • A cost for each named CMS user or editor or a concurrent user limit .
  • A cost depending on the environment e.g. development, test, staging, production and disaster recovery.

Useful replies from @scrump & @proops below :

scrump_cms_licensing

One size does not fit all

proops_cms_licensing

twitter post regarding Modules and maintenance

scrump_aftersale_cms_licensing

scrump_requirements_cms_licensing

When buying a CMS what are you buying ?

To try to answer why it is complicated let’s look at what you are actually purchasing :

Product Description
Core product This is usually the CMS server. As above the price of the core product will depend on the number of sites, users, servers etc.You will want to ensure that as many of your requirements as possible are covered in the core product.If you need additional functions then you will need to look at the availble modules.
Modules Any number of modules may be required to meet your requirements, this is an area where you could very quickly blow your budget! Possible modules include: Personalisation, dynamic delivery, social media tools, digital asset management, e-commerce catalogues, integration with third party products like Sharepoint, CRM systems etc.Modules may be licensed similarly to the core product and will attract additional costs on for each environment as well as ongoing support.
Databases & Application servers This will need to include licenses for Oracle/SQL Server database and applications servers etc.
Hardware Architecture You have to factor in the architecture as the number of Servers & CPU’s may affect the final price.It can be difficult to establish the architecture at the outset as with a dynamic CMS it depends on how the CMS has been implemented and how it will scale. Usually a sizing exercise is required which looks at the traffic levels now and into the future before a recommended architecture can be arrived at
Non production Environment licenses Non production environments also attract a cost though this is usually at a fraction of the full price. These could include Test, development and disaster recovery environments.
Maintenance & Support This is an annual subscription cost which is usually around 18-20% of the list price, and not 20% of the discounted price you may have managed to negotiate!

In summary :

Buying a CMS is fairly complicated as it involves buying software as well the hardware, hosting and support. Having a complex model may be necessary because:

  • One size doesn’t fit all. Why should you pay for functions that you will never use? You will not have the same numbers of users or sites as the next client.
  • Modules provide the flexibility of including additional functionality at a later time. This allows clients with a lower initial cost to get started. However modules can significantly increase the CMS license cost as they may also be licensed by site and users, there is also the additional support & environments costs to be considered.

What I would like to see is:

  • Openess and transparency in pricing. A fixed price list, with same prices for all customers. I regularly see quotes provided to more than one client at the same time, and know what is each
  • Simplified pricing. As above a standard price list so that clients know how much each and module costs, and what would happen if they changed X. We all know the price of an 60 GB Ipod classic.
  • A definition of what is a site. Clients may need to implement microsites for marketing campaigns under specific domains, are these sites? Even if they are shortlived ? What about subdomains?
  • Serious thought given to CMS scalability and performance as part of CMS selection & licensing, how will the architecture scale to cater for additional content and site visitors? Architectural changes further down the line could impact on the licensing e.g. additional servers and CPU’s usually mean additional license costs.

What I would welcome the end of :

  • Highly inflated “optimistic” list prices which are then heavily discounted.
  • Pricing by
    • CPU core, dual core are now more expensive the quad core.
    • Registered public user
    • CPU Megahertz (I think this practice may be dead, but is related to CPU cores).
    • Content Editor, concurrent editors make more sense.
  • Additional costs for commodity functions such as blogs, forums, surveys, polls, accessibility checking, link checking etc. Clients expect do not pay extra for these functions.

What has your experience been when pricing CMS systems, has it been straightforward or are you having to go back to the vendor every time a change is needed?

If you are thinking about building a team or are a developer and are thinking about skilling up and were wondering what the trends were in todays CMS jobs market, I think you’ll be interested in this excellent UK based resource which provides CMS job trends from data gathered over the last couple of months and compares it to the same period a year ago. The data presented in this post is from 3 months until 11th September 2009.

The salient points about the CMS jobs trends for me are :

CMS Jobs demand

The total number of permanent jobs is down from 2086 to 1152, however the proportion of jobs is up from 7.7% to 10.42% since last year. The graph below shows the demand trend from May 2004 showing a steady increase.

CMS jobs demand trend from 2004 to Sept 2009

CMS jobs demand trend from 2004 to Sept 2009

Salaries

The average salary is down by 7% from £35,000 to £32,500 which appears to be the lowest average since these records bagan in May 2004. The range of salaries has also narrowed with the 90% percentile now around the mid £40k’s, more evidence that now is the best time to hire.

CMS jobs salary trend from 2004 to 2009

CMS jobs salary trend from 2004 to 2009

The salary histogram below shows the most of the jobs are concentrated between £25k – £40k, hiring developers isn’t going to be cheap, however this range also provides developers with salary progression in line with their experience. There is the usual “long tail” of salaries upwards from £50k showing only a small number of senior opportunities available.

CMS jobs salary Histogram

CMS jobs salary Histogram

Application Platform

The table below lists the applications platforms mentioned in a CMS jobs over 6 months period until 11th September. The list is a mix of java/.Net/LAMP technologies and Commercial and Open Source software. There is a large number of .Net platforms e.g. Episerver, Sitecore, Umbraco and Immediacy joined by Open Source LAMP based ones notably Drupal & Joomla.

CMS application platforms

Application development

No suprises that the table below shows that web interface development and .Net dominate the skills required for CMS development.

CMS application development

CMS application development

Your thoughts?

What does these trends mean to you?

As a developer or an agency would you join the ranks of those providing services on the most popular application platforms or concentrate on what you knew, irrespective of what the market was looking for? As for salaries, would the drop in average salaries influence you in anyway?

As a CMS buyer would you factor in a particular application platforms market presence and the number of skilled developers and agencies that specialised in it? Would you rule out a CMS if it didn’t have a large base of developers or partners?

It is going to be interesting to see what these trends might be like in a year or two’s time and whether todays major players are still in demand tomorrow.

Why are RFP’s so long?

August 13, 2009

A problem we find consistently with CMS selection and procurement is the desire to include as much content as possible into RFP’s, these documents are usually over 40 pages and make a daunting tasks for vendors and suppliers to read through and respond as well increasing the (already busy) workload of the procurement team tasked with authoring and reviewing it.

Janus Boye in a blog post presents some of the reasons why RFP’s might be so long

In this article I’m hoping to present some of the options available to you to assess the usability of a CMS you have on your shortlist. This article discusses steps you can take to help you build a picture of how the CMS functions and how it might be used to fulfil your needs.

I thought about writing this article because :

  1. CMS usability is very difficult for vendors to attain, most CMS are very complex consisting of suite of applications catering for users of all abilities (from junior editors to system administrators).
  2. CMS usability is difficult to assess. You may not have the time or resources to give the product a proper test drive, or be overwhelmed by the sheer amount of functions available.

Developing use case scenarios

Stephen Krug’s book “Don’t make me think” tells you precisely how you should go about usability testing. You’ll need a small number of authors and editors (at least 3-4 to make it worthwhile) and a list of scenarios which encompass the most common tasks that you will be performing, these scenarios might include:

  1. Creating new content. Creating a new article (with images) and promoting it on the home page, relating articles – either directly or via meta data (such as a taxonomy)
  2. Updating and approving existing content (include user generated content). This would demonstrate workflow and approval processes and versioning capabilites.
  3. Updating design. Modifying layout of templates and page design elements

Getting your hands dirty

There are a number of options presented below, each depends on the time, budget and resources you have at your displosal. You are likely to be looking at more than one CMS during the vendor and online demos, and looking at going on training and a procuring a proof of concept only for your preferred solution.

  1. Vendor demo
  2. You go through the product with the vendor, a well-managed vendor demonstration should provide a pretty good idea about the usability of the product. These demos usally last around two hours which is usually not enough to get an in-depth understanding of the product, but it’s a good start, and should help you narrow the field.

  3. Online demo
  4. Most vendors will be able to provide you with an online demo site for their CMS. This offers a simple way of playing with the product in your time and using your own equipment. The demo won’t be populated with your content or have your site structure, however it could give you a good feel for how everything fit’s together. A word of warning though as almost every CMS requires training, simply playing with a product could be potentially misleading and can become very easily frustrating!

    Ideally you would want to run through your most common scenarios on the demo without too much input from the vendor. If you can without getting confused or disoriented then it bodes well for how others will be receptive to it.

  5. CMS training
  6. Ask the vendor about end user training for the CMS. This will help to answer many questions: is training available? Some vendors don’t provide user training as they believe that their product doesn’t need it! If it’s needed how long is it? 1 day or 5 days? Some authors could be sent on training to find out how simple the product was to use? Can the authors understand the product at the end of training?

  7. Proof of concept
  8. You should ask the vendor to create and deploy a proof of concept based on your scenarios for you to work on. You can then conduct scripted tests with trained users to help identify any major issues.

Even with using the techniques presented here, CMS usability can still be difficult to assess e.g. what is simple for one content editor could be difficult for another. Nevertheless, I believe it is vital to conduct an evaluation of usability as part of the CMS selection process, and it could be the difference between project success and failure.

Is usability testing a part of your CMS selection process? What has worked for you?

Links

Don’t make me think (usability testing by Stephen Krug)

Practical ways to assess CMS Usability

When speaking to clients and CMS vendors we have been discussing what is the most important criteria that CMS buyers are looking for when selecting a CMS. A year ot two ago I would have said it was cost or how well a CMS met requirements. However in our most recent projects usability has been as important as cost or how well the CMS met a clients’ requirements. So why is it important and why does it feature at all in CMS selection projects now and what do we mean by CMS usability?.

What is CMS usability anyway?

Usability means making sure something works well, and that a person of average ability or experience can use it for its intended purpose without getting hopelessly frustrated. Therefore a usable CMS will :

  1. Be easy to learn
  2. Be easy to remember (particularly for occaisional users)
  3. Have a simple content management model (content types, ‘pages’) and follow a users’ mental model
  4. Require minimal training and be easy to explain to non web savvy editors.
  5. Be fast, resilient and error proof.
  6. Provide helpful error messages and tips when things go wrong. (wishful thinking!)

Clearly these things are not always covered in a statement of requirements, and have a significant impact on a successful CMS project.

Why is usability so important?

  1. Project failure is not an option (particularly now). If a CMS has been selected based on primarily technical or value for money criteria then there is a siginificant additional risk the project will fail!
  2. If  your team does not understand the CMS they will not use it.
  3. You will have to factor in additional hidden costs of training (of existing and new staff) and support. Your team will be inundated with support requests from users who will get stuck and then your team will spend time helping them.
  4. Devolved content management will not be possible, without significant additional investment.

What do you think? Does usability feature in your CMS selection? If not why not?

Useful posts on CMS usability:

  1. 11 usability principles for CMS products (Step Two Designs)
  2. The 5 hidden costs of running a CMS (Paul Boag)