Over the years I’ve worked with many content management systems (CMSs) and seen many lists of CMS requirements. I’ve read Deane Barker‘s (phenomenal) book Things You Should Know, as well as numerous blog posts, and even helped a few organizations migrate from one CMS to another. Yet when my team began discussing the ideal CMS for our own team, I was at a loss: where to start?
Start with what you know
When it comes to most projects, it seems to make sense to start with what you know. As I said, I’ve worked with many CMSs before. So it seemed like I should make a list of the CMSs I had worked with, and the pros and cons. But there are many, many CMSs out there. My experience is only with a few, and none have been “perfect”. In addition, as a content strategist I don’t see what has been customized by my eng team. So I don’t know what the CMS might have looked like “out of the box“.
Starting with what I know seemed like it would fall short.
Start with what you don’t know
Another option was to approach this as a discovery. I don’t know enough to simply select a CMS – and neither did anyone in my small working group. So perhaps we could make lists of everything we didn’t know but wanted to know.
There were two issues with this approach. One, as Deane Barker says, was time and budget to explore:
Given that CMS and marketing functions are not a line of business concern, many organizations consider these projects to be outside the core mission and they’re left to fight for resources and attention.Things You Should Know, Deane Barker
This was certainly true for us. No one had quite enough time to dedicate to exploration. But the other issue was a sense of uncertainty. Where do we start? How do we even know what we don’t know?
Start with CMS requirements
As we talked about what we needed from a CMS, we kept coming back to examples. “If I was publishing an article, I need to make sure I can later archive that.” “That’s something I would want to reuse.” “For compliance, every editor needs an official sign-off.”
It became clear that the CMS requirements were there, just in front of us, if we could just write them down. This led us to creating user flows, where we walked through the steps different roles would take to create, edit, publish, and review content. For each step, we broke down the requirements that helped accomplish the step.
While our CMS work is far from over, I can now confidently say what we need in our system. Our CMS requirements will guide the way, with far more certainty than I would have had trying to pick a CMS I already knew.