While most of my consulting work is in product selection, I think the most interesting and rewarding type of project is evaluating the results of a CMS implementation. The typical scenario is that a client feels like their CMS project didn't yield the expected results and engages Content Here to identify what went wrong and what adjustments should be made. Without this type of analysis, it is typical for a buyer to grumble and suffer with the solution for the next three or four years until they have the money to replace it; then the cycle repeats itself because nothing was learned from the experience.
When evaluating a CMS implementation, I typically look at three dimensions: expectations, product, and project.
Expectation rationality. Too many projects are doomed from the start because the expectations were set too high. It is often useful to have a third party assess whether the project was oversold or if it under-delivered.
Platform suitability. Choosing the wrong CMS product also puts the project in jeopardy. The platform should support your requirements, feel intuitive to your users, be maintainable by your team, and be supported by a well run company that can be a compatible partner.
Project execution. The project to implement the solution should be appropriately scoped and phased to achieve short term results quickly and work toward long term goals. You need to select a competent integration partner (internal or external) that you can trust and collaborate with to make good decisions. Your users need to be well supported with training and coaching.
Failure in any of these areas makes a buyer miserable but some are more correctable than others. Choosing the wrong product is the hardest mistake to undo. Migrations are always hard. Even if you can get the data over, all the work to customize and configure the wrong solution is non-transferable. However, it may be possible to minimize the impact through customizations and work-arounds. Generally, these systems are flexible enough to achieve some level of comfort even if it is not ideal.
Irrational expectations is the easiest problem to correct. For example, if it was unreasonable to expect that everyone in the organization (without training) would autonomously contribute their own content, maybe you need to keep that web coordinator role. Maybe some of the benefits will not be immediately realized after the first release of the solution. It is fairly typical to do a few subsequent maintenance releases to expose new functionality or correct bad design assumptions. Ideally, this should be a living solution that is constantly evolving and improving. You are not going to get everything right the first time.
Even though no implementations are perfect, some projects go better than others. Inexperience is the biggest culprit. You want to work with an integration team that is familiar with the technology (on most platforms, it usually takes 2 to 3 substantial projects to establish best practices and patterns). You also want to work with a team that has done similar scale projects, understands your industry, and can speak your language. It is easy to misinterpret requirements and make bad design assumptions if you don't have a suitable context. Sometimes a rocky implementation with a new vendor is part of a natural learning process and things will improve. Other times, it is a sign that two organizations are incompatible as partners.
If your organization feels disillusioned by a recent CMS implementation, the good news is that most problems can be fixed without having to start over. All that is needed is a solid understanding of what went wrong and a roadmap of corrections. Over time, the solution will probably be able to achieve all of the reasonable expectations that you had for it. Let me know if you need help evaluating your CMS implementation. Content Here can put you on a path to improving it.