I’ve seen a few content management system implementations in my career, both as implementer and as client. Here are just a few lessons I’ve learned along the way.
A common mistake is thinking that a CMS will bring down the cost of web development (or whatever you want to call it) at the institution. Nothing could be further from the truth. It will be way more expensive than you ever imagined.
What you will really need
Your CMS isn’t going to run itself. And someone will have to be responsible for making decisions about policy, updates, priorities et cetera. You’ll need some kind of governance structure. It should not be in IT and it should include key stakeholders. Your key stakeholders will vary but at the very least, I recommend at least one high-level administrator in your communications office and several people who represent your user population.
2. Project management
A lot of it, starting well before implementation and on-going after launch. The last thing you want is a lot of ad hockery once you’ve launched your CMS. Your project management process will require guidance from your governance structure.
3. A system administrator
You want to keep the thing running, right?
4. A software developer
If you believe your CMS is plug-and-play, I have some property you might like to buy.
Seriously, you’ll need at least one person who can hack at, tune performance and program widgets for your CMS. I have yet to see an out-of-the-box CMS that did everything a client needed.
5. More hardware
You need more than just the production server. You need development systems, QA/testing servers and possibly more. Most CMSes benefit from some kind of front-end caching. Add that to your server list.
6. Continuous training
Not just for your early users… every person that comes into the CMS will need training. And retraining, because your CMS will change, you’ll add new features, people forget et cetera.
7. A help desk
Your users will have questions. Most of them will use your CMS very infrequently. The longer they go between uses, the more they forget. Oh, and your CMS will break. Users hate that. They need a place to report when it breaks.
Frequent, open, bi-directional and informative. Developed a new component or added a new widget? How do you think your users will find out about it? And you need to open your ears. Your users, especially frequent, power users, will have a lot to say about the CMS. Some of it can even prove useful.
Your users need a lot of it. Your vendor might provide some, but likely it’s written for and by their developers. You need user documentation. You need a place that the help desk can point to when someone calls with a problem. You need a place you can point to when you announce new features, components or widgets.
10. A contingency plan
What are you going to do when the CMS crashes and takes down your website? Not just for low-impact, middle of the semester crashes, either. I’m talking about when it crashes during drop-add or a campus emergency. Do have a plan for those situations?
11. More money, more time, more people
Sorry, you need all three. There’s no way around it.
Plan for the service (because you launched a service, not a product) to grow more expensive over time. The bigger it gets, the more resources it will need.
It takes way longer than you think it will to do anything. For any estimate of time required, just double it. If you come in under time, you’re a hero. If you’re on time, you were prescient. And if you’re over, well, adjust your multiplier.
And you will quickly reach a limit on what your people can do. That single developer you though would do everything? Well, on day two after your launch, that person isn’t just developing new code. He’s doing bug fixes on existing code. He’s tweaking templates for your designer. Every new component/widget you add to your CMS adds to the support cost and subtracts from time that can be allocated to development.