A few weeks ago, I received an invitation to provide consulting support to a professional association here in the UK as they went out to tender for a CMS. The document provided a very clear analysis of the requirements of the association, but then I came across a disquieting statement to the effect that the association was going to purchase a CMS for its Web site (including the provision of a shopping basket for publications and the opportunity for members to update their personal information) and that, at some time in the near future, it planned to migrate its intranet into the Web CMS.
In my view there are some significant risks associated with specifying a CMS for either a Web application or an intranet and then assuming that it will be an ideal solution for the other. Of course the driving force behind consolidation decisions is usually an economic one: just one license fee to pay, and as a plus, everyone can be trained up on the same software. The reality is different. I always advise my clients that the only way to select a CMS that will meet the requirements of a Web site and an intranet is to develop the specifications for both and then look at the trade-offs that have to be made to accommodate the requirements of the two applications in the same CMS.
In one of the games I play in my CMS workshops, I ask delegates to give me a list of the similarities and differences between the content management requirements of a Web site and an intranet. They start off thinking I'm slightly mad and then find the list of differences is substantially longer than the list of similarities.
In most organizations, only a limited number of people will be using the Web CMS to publish pages to the Web site. Although I have come across organizations that do allow all staff to be publishers, these are the exceptions rather than the rule. Because a limited number of employees need to publish using the CMS, it is very likely that they will be able to cope with a complex process and be able to manage graphics and the like because they use the system almost every day. Metadata on a Web site is also probably less of an issue because the usual objective is to get a good position on a search engine site. Providing users with good search functionality within the site itself is usually (and wrongly) not seen as a priority. One other difference between a Web site and an intranet is that external link management is usually less of an issue with a Web site, as the last thing a Web manager wants to do is to push a visitor off to another site.
Now let me look at the situation from an intranet point of view. Even if the plans are not to make every member of staff a publisher, there will certainly be a much wider range of contributors to an intranet than a Web site. This range is not only in terms of skills but also in terms of the frequency of use. Intranet contributors may only be using the CMS on a very occasional basis, perhaps only monthly at best. They will be looking for very good Help functionality, preferably contextually generated. Accessibility will be more of an issue, because some publishers may have limited sight or poor control of a mouse.
Two of the major differences are that there will almost certainly need to be good search functionality in an intranet application (either built-in or third-party), and this also means that metadata management has to be top-rate. File types may vary and will almost certainly include PDFs and PowerPoint files, which will be less common on a Web site.
And the list goes on. I am not saying for one moment that there are no CMS products that can support both a Web site and an intranet. I have been involved in some successful installations of this sort. But in these cases the organizations have set out clear requirements statements for both applications and then found that, in their particular case, it was possible to implement a single CMS. Usually White's Law of CMS products applies: All the products can meet 80% of your requirements. Unfortunately it is a different 80%!
As with any CMS implementation, the amount of work that is undertaken prior to the implementation always has a direct impact on the success of the selection and implementation process. It cannot be rushed and must be carried out with an open mind—if not with an open checkbook. To the finance department the benefits of purchasing just one CMS are usually quite overwhelming. Then again, how often does the finance department staff contribute to either a Web site or an intranet? Caveat implementor, as they say in Rome.