This series offers advice for tackling challenges faced by web professionals just trying to do the right thing in higher ed. While a Girl Scout, I was taught to leave a place better than I found it and choosing the right web content management system for your campus does just that.
Web content management systems: a lot to choose from and a lot to consider. And, if you are taking the expectations of your web editors into account – and you should – the decision about which CMS is daunting.
For some, it will be unexpected that this post about choosing a CMS is not about technology. If you need a comprehensive review of software specs and functionality, the @wm_creative blog can be a source for that. Since deploying Hannon Hill’s Cascade Server in April 2008, William & Mary Creative Services has written extensively about all things Cascade. But today, I’m writing about leaving your campus better than you found it by gaining acceptance for one CMS from hundreds of campus web editors.
There are a lot of opinions on a college campus. Sometimes, the collective viewpoints are like a thousand flowers blooming and sometimes, they are like a big hot mess. Enterprise software brings out those opinions in abundance; understandably, people immediately personalize the experience and reference the very mundane and the very unrealistic. At the end of the day, a web CMS is supposed to allow decentralized editing of content on web pages. If you do it right, you can also control design and prevent blue and red flashing text.
About 800 individuals at William & Mary use our web CMS. Selection of enterprise software to replace a home-grown web templating system was within the scope of the re.web Project and we launched the new CMS in parallel with a relaunch of wm.edu. In a nutshell, here are a few of things that contributed to success:
We shared the specifications and functionality list with anyone who asked.
We followed an exhaustive process for evaluating dozens of CMS products using a comprehensive list of specs and functionality. Campus web editors who asked for and received the written documentation were a) convinced we had this thing under control, b) thrilled the decision was in our hands and not theirs, and c) glad to see the thing they were most hoping for on the list.
We offered on-campus demos of two products and asked for feedback.
At our invitation, more than 100 individuals attended two demonstrations and were encouraged to ask questions, share thoughts, and gain an understanding of the benefits of enterprise content management. Initially, our only goal was to gain consensus by encouraging feedback; ultimately, I think the CMS training we later offered was more accessible because of the early orientation during the demos.
We focused on the William & Mary experience.
Whenever possible, we narrowed the decisions and possibilities to the William & Mary version of a new CMS. Here are a couple of examples to demonstrate what I mean. First, we used our external partner for the demos mentioned above and we provided a script. So our editors saw the CMS options the way they would be used on our campus. Instead of a sales rep demonstrating CMS features that we knew we weren’t going to deploy, an objective person showed a series of tasks in both products. This allowed our editors to compare apples to apples. Second, web editors learned to use the new CMS by working on their own websites. Migrating, editing and updating their own content in the new tool meant they were more invested and more comfortable.
When a choice had to be made, the experience of the web editors trumped.
Like any IT professional, I know that the simpler on the front end, the more complicated on the back end. For us, key to the campus-wide adoption of a new CMS was easy to use. We learned that you can’t just run a list of specifications against the vendor’s functionality list. Most CMS products can do what you want; but once you test drive, you might find you don’t like the way they do want you want. In the final assessment, we let the user experience drive the decision even when it would mean more complexity for the team behind the curtain.
What say you? Would any of the above matter for your CMS decision-making process?