We've been doing WCM/CMS implementations at Oshyn for many years. While these types of projects have many of the same steps as other web projects, there are some distinct things that are unique. There are many best practices about how to do user experience, technical architecture, information architecture for websites, however, in this series, I'd like to focus on some key things that are different about WCM projects across the typical project lifecycle.
Before you start
Here is a list of things your executive team can decide from a high level before the project even begins:
Will this be a redesign or a replatform? - a redesign means getting touching the Information Architecture, Visual Design, getting approvals, etc. A replatform usually will only involve IT staff with minimal business involvement with the main requirement being "make sure it still works the way it does currently".
What are your main objectives and who do they target?
- Improve your editing capability?
- Offer new features for your site visitors?
- Consolidate sites or have better code re-use (i.e. improve maintainability)?
- Something else??
Is baking or frying more appropriate for your needs? (more info here)
- Baking: large amounts of content, mostly in "broadcast" mode, little user interaction on the site other than consuming the content
- Frying: high degree of user interaction and personalization, possibly UGC is required
Keep in mind that many vendors have evolved their products to overcome the natural limitations of their chosen architecture, however, even in the best case, these are still particular items that need to attention for packages in each category.
Who will maintain the site?
If your internal team will, then their skillsets will be an important component to your platform selection. Will it be .NET? Java? PHP? Do you have an HTML person technical enough to edit templates? You may have to think about training internally or finding the skills for ongoing maintenance outside your company
What will your cutover strategy be? There are typically two options:
- Big Bang - this will likely entail a 'content freeze", but will be cheaper in the long run
- Running Parallel - this will be more total work, but will enable you to go live earlier. Content will be required to be entered twice, old systems will be required to be maintained AND additional functionality (which would not be required in Big Bang) will be required to be developed. Companies with large amounts of content may elect to follow this strategy in order to get to market sooner with their higher priority features and content