The other day I was trying to describe to a client how content management systems are different. My audience was not familiar with some of the core features of a CMS so my examples were too abstract to get my points across. However, they were familiar with Microsoft Office so I used that as an analogy. They found it quite useful so I thought I would repeat it here.
The Microsoft Office Analogy of Web Content Management Systems
Imagine your boss wants you to "put down a few thoughts" on a topic to share electronically with a group. You might choose to create a Word document, a PowerPoint presentation, an Excel work book, or maybe even an Outlook email message and then start typing out a list. Because you just want to capture some ideas and your boss was so vague about the format, it doesn't really matter what you choose. Your boss asked for ideas, not a deliverable. Let's say you choose PowerPoint because you have a nice looking master template and you figure a few bullet points would look nice in big text on one slide. It doesn't hurt that you are really comfortable with using PowerPoint.
So you show your boss the PowerPoint deck and he wants you to elaborate more. You have used terms that need to be defined and he wants you to support your points with some background information. This "few thoughts" is starting to sound like a memo or a report. Now PowerPoint is not looking so good. What do you do? You can start to overload PowerPoint's features to make it work like a word processor; or bail out and copy/paste everything into Microsoft Word. You will probably make this decision based on how familiar you are with PowerPoint vs. Word, how particular your boss is going to be about the format, and how long this document will live. If you make the wrong decision, fighting the technology will start to dominate the time you spend on this project. Every change will risk blowing up the whole document.
Strengths and Weaknesses
Like all analogies, this had its strengths and weaknesses:
Many companies choose a CMS for arbitrary reasons without really understanding their requirements. When requirements are vague (like "we just want a simple website"), all options look equally viable.
Stakeholders often have tacit but very specific requirements. e.g. "I will know it when I see it."
If you really know a technology, you can force it on a problem by overloading features and redefining the problem. For example, while the MS Word user sees a bunch of paragraphs, the PowerPoint user sees a series of vertically arranged left-aligned text boxes. However, eventually these solutions tend to become unstable, especially if they need to get supported by different people.
You need to know when to swap tools. If you do it too late, you waste too much time misusing the old technology and you have more content to move over.
My client immediately wanted to know which CMSs were like Word and which CMSs were like PowerPoint. You don't want to go too far with this analogy because a CMS is more than a document editor.
The switching costs from one CMS to another is much much greater that from one document format to another. If this was a CMS implementation, you want to ask your boss to clarify where this project is going before you pick your tool.
While not perfect, I think this analogy did its job of making people think about CMS selection in terms that they can relate to. They can now visualize themselves misusing the wrong tool to get the results they want and living in constant fear that one more hack is going to bring the whole site down. They are now thinking about their website in terms of a development roadmap that will be influenced by different stakeholders over time. They can relate to how people have a difficult time expressing requirements that they know tacitly and can apply familiar skills to get clarification. As long as I can keep them from over identifying the website with a MS Office document, I think I am going to be OK.