Hands Off That Code!
Unofficially titled "Top Ten Mistakes: How to Avoid the Liferay Hall of Shame," Chung drew on his ten years with the company to highlight the most common practices that get people into seriously hot water. One of the biggest strongly applies to much of the open source CMS world: When at all possible, avoid directly editing the project's source code.
What's the good of using open source then? Their point isn't that you should never modify or extend the software. Products such as Liferay along with the big open source CMS's like Drupal (news, site) are designed to be extensible. But if you directly edit the source code, you're setting yourself up for a world of pain. Suddenly it's hard to upgrade or even apply maintenance and security patches because you have to watch out for over-writing your changes.
Instead, use the project's APIs, hooks and other extendability features to make the modifications you need. You'll thank yourself the next time a vital security patch comes around.
Plan, Plan and Plan
Many organizations leap into implementation without ever stopping to do two key planning steps: determine your performance needs and ensure that your users are also stakeholders. Those who neglect to do things like project how much traffic and how many users they can reasonably hope for, what types of use load scenarios they envision, what type of test cases they need to run and what type of caching strategy they want to implement can find themselves in a situation where they have to either throw a lot of new hardware at a poorly-designed system or re-architect everything from the ground up.
In the case of the users, many project teams dream up features without ever asking what people want from the result. Without knowing what people need in order to do their jobs, or ensuring that the people who need to use a section of the site actually find it useful, you can end up with hundreds of hours of work sitting there unloved and completely unused. Also, Chung suggested ensuring that at least one executive in the related business unit is completely behind the project and engaged in both driving requirements and helping to improve user buy-in.
Other ways to ensure that what you build is a success include doing usability validation with your target users, defining roles and responsibilities clearly, and finding ways to make it clear that this new project is going to make everyone's lives easier. The best way to make that clear is, again, to engage the target users and then really deliver on what they need.
Less is More
We all like our work to have a slick, polished look. The "there's an app for that" universe helps toward this end but it also causes many busy, frankenstinean sites and products full of unnecessary features. Liferay offers over 60 plugins. Projects like WordPress (news, site) offer thousands. Don't add plugins because people might want to use them. Add them because the plugins serve the use cases and business requirements you've defined for your project.
In addition to feature creep, another problem Chung identified boils down to, "One portal to rule them all." It's common to decide that you want a lot of different things to live within your portal. There's no problem with this decision, but if you try to build all of these items simultaneously, you risk never actually finishing even though months of time and money have been sunk into the effort.
He cautions to think of ROI from the beginning and how to break the project into phases. For example, you might first roll out your new website. From there, you might build out the intranet. Then the collaboration tools, social tools and various custom enterprise applications.
How Do You Know You're Done?
If you haven't defined key performance indicators and ways to monitor usage, you won't know when to rest on your laurels and when to tweak performance or do more usability work to improve things. More importantly, though, in some ways you're never fully finished. Chang pointed out that many people seem to forget to provide for who is going to keep the end product up to date with maintenance and security updates, not to mention how upgrades will be handled.
Security patches should be applied immediately. For the rest, be sure to know who is responsible for updates and have a process in place for handling them.
To Invest Or Not To Invest
Cheng's final suggestions might seem a little self-serving since they involve paying for training, enterprise versions and support. However, if you assign a staff of generalists to roll out a complex enterprise solution for mission- or business-critical purposes there are some things to consider.
For example, the more complex the product, the more worthwhile it can be to include one or more levels of training (developer, administrator, etc.) for at least one of your staff as a kind of scout. Doing so will help your organization better understand whether the free version can do the job and what best practices are for that particular package. Not to mention that for mission- and business-critical applications it's better to have an existing support contract up front than having to call the vendor in a panic when something goes terribly, terribly wrong.
Heed a lot of the advice in this article and things might just go wonderfully right.