James Robertson of Aussie firm Step Two has published an article entitled Top 10 mistakes when selecting a CMS. His short take is that organizations make the selection process much harder than it needs to be. And we couldn't agree more ...that is, when they do actually take the time to think the details through.James' top 10 list is focused on Web CMS procurement and sports the following list of purchasing blunders: # Not understanding the problem to be solved # Not understanding content management issues # Assuming there are only a dozen possible products # Bigger is better # Not distinguishing between requirements and selection criteria # Writing too many requirements # 'Complies' / 'does not comply' # Focusing on the 'what' not the 'how' # Confusing the CMS project and the broader website project # Running the selection as a technology project Procuring larger software packages which touch many different organizational operations and end up with public faces is tough. Simplification is good, but there are limits to this and in the end its a complex process that requires informed management. The problems start once you gather three or four very different groups with very valid, but completely disparate concerns, and then find that none of the groups have a good grasp of the others' pains. For example in line with James point # 10, do the content editors give two cents if the system is written in Java or Ruby on Rails? Hardly. Does the Web Services integration team really get concerned if the public rendering engine produces Google-friendly HTML? Do the template designers trouble themselves over the dictionaries supported by the spell checker? We think not. We think James hit the nail on the head with point #1. The biggest problem is a lack of experience in the procurement team. Most people selecting CMS software have little experience doing so and/or have been out of the space too long. Mis-characterizing the issues, ill-defining the project boundaries, or complicating the requirements all flow readily from a lack of experience and sometimes from too broad a consensus building effort. Finding your experts -- either internally or externally -- and empowering them is task number one. James has a habit of providing practical advice when defining requirements. His latest article is in keeping with this history and certainly one for the CMS procurement toolkit. Similarly, CMS Watch's recent discussion of scenario-based CMS vendor evaluation is a valuable read for those seeking to find their next darling of a CMS software investment.