When I help companies through a CMS selection, I focus on the whole solution rather than just the functionality of the software. Factors such as vendor compatibility and expertise availability (internal and external) also affect the sustainability of the solution &mdash sometimes even more than the feature set. Several of my recent consulting projects have de-emphasized the software component of the solution even more. These selections were part of larger initiatives that required significant help from an outside partner. In one case there was a comprehensive site redesign that included digital strategy, re-branding, and information re-architecture as well as implementing new functionality. In another case, the client was shifting to an outsourced model where a partner was to maintain the full infrastructure and assume all development responsibilities. In situations like these, while the software is important, the biggest risk is choosing the wrong partner to work with.

A dual selection like this poses a real problem. If you focus on the partner, you have the software choice made for you. I know that there are systems integrators that claim technology agnosticism but I seriously doubt them. The truth is that it takes a couple implementations on any platform to get it right. In some cases, it takes many (like 5) projects to run out of ways to mess things up. That is the downside of flexibility. So, when someone says “technology agnostic,” I hear either “we don’t have skills on any platform” or, like the the waitress at Bob’s Country Bunker said: “Oh, we got both kinds [of music]. We got Country, and Western.” It could be even worse: the integrator who claims neutrality can be paid by the software vendor to recommend a solution.

The other option is to go with a pure design agency and select a product (and integrator) afterwards to implement that design. This can be inefficient because the designers can arbitrarily and unknowingly make decisions that make implementation harder. You will probably need to rescope and refactor the design based on the native capabilities of the platform you choose. A lot of time can be saved if you have someone to suggest more efficient options during the design process. I know I am going to get slammed here by developers and software companies saying their product can do anything. If they could, they would have 100% market share. Pure strategy and design companies also tend to underestimate the cost of implementation so you might running out of money when it is time to implement the design.

It’s a chicken and egg problem. You can’t choose a product until you have had help with your requirements and you can’t get help with your requirements until you choose a development agency (that implicitly comes with a product). I have found this variation of my standard process to be effective.

1. Gather the requirements that are the most meaningful to a product selection. I call these leading requirements.
2. Use these functional and non-functional requirements to filter down the software marketplace to a very short list of product options (probably no more than two).
3. Find a couple of the best web agencies who specialize in working on either of these platforms — ideally, two for each of the two products.
4. Invite these agencies to present a solution based on their preferred platform. Like in my normal selection process, the presentation consists of the demonstration of scenarios that you defined when you gathered your leading requirements.
5. Evaluate the presentations across two dimensions: the product and the agency.

I have found this process to be extremely effective. The benefit that I didn’t anticipate was that the preparation of the prototype tested three very important aspects of the integrators: their consultative process for turning customer articulated requirements into a solution; their mastery over the platform; and their relationship with the software vendor. But the process is not perfect. Here are some issues:

• A professional services company has lower margins than a software company. They don’t have the prospect of an all-profit software license deal to justify a big bet on a sales initiative. Professional services companies will put up with a lot less run around than a software company will — especially the good ones. So the process has to be efficient and they need to have a good shot at winning. This means that you need to: have a short list of no more than four integrators; have budgeting worked out before you contact with them; and work together with them to get what you need. This collaboration is also useful in getting a feel for what it will be like to work with the firm.
• Some integrators have dedicated sales teams that can prevent you from getting to know their consulting capabilities. You should do everything you can to work directly with real consultants. Not only is it important to learn about their style and capabilities, delivery staff are less likely to tell you what they think you want to hear.
• Those filtering steps (1-3) are very hard if you are just learning about web development and don’t know your way around the industry. You need to talk to lots of people and learn from their experiences or work with someone who has.

Despite all of these challenges, doing a dual selection is not impossible. In fact, it can be quite fruitful. You just need to be focused and disciplined in your approach and execution. If you are interested in learning more, I am teaching a workshop on Selecting a CMS at the Gilbane Conference in Boston on December 1st. I hope to see you there.

Related posts:

1. The Dead Zone of Software Pricing

This entry was posted by Seth Gottlieb on Friday, November 20th, 2009 at 6:52 am and is filed under selection.You can skip to the end and leave a response. Pinging is currently not allowed.