Blogs

The other day I was in a meeting with department heads from across the country.  Everyone had flown in to review some design options for $20M+ ECRM implementation that will bring profound changes to how they do their operations.  The system involves a little less than 20,000 users.  It will be a transformational project for the organization and there have been a lot of senior people who aren’t shy about voicing their opinions. 

Of course, some of those people also have “Chicken Little Syndrome” where everything they see is potential failure.  “The system is too big”.  “How will we transfer that much data across the WAN?”  “Can we find enough people with the right skills to deploy and maintain it”.  They are questions that everyone on this blog has heard in their career.

After letting the groups talk for a considerable amount of time I spoke up and pointed out that, yes, there are many reasonable concerns.  The issues that they raise are indeed valid business, technical, and operational issues that must addressed.  But I also pointed out that while they may feel big with 20,000 users, the reality is that they are not forging any new paths in terms of how they will use and deploy the technology; there are numerous organizations who have already addressed these issues and, for some, they have departmental implementations that are bigger than this entire project.  I then proceeded to roll off a list of large projects that had all dwarfed the respective areas of concern.  At the end of the session everyone realized that the project was big, complex, and still fraught with risk, but it wasn’t going to be anything that couldn’t be addressed.

That got to me to thinking:  there are plenty of reference projects that can be found.  The question really becomes one of knowing the right questions.  Here are what I look for when making comparisons to other organizations:

1. User Population Size.  Obviously numbers of users is a big correlation although sometimes it takes a little digging under the covers.  For example, a system with 50,000 licenses for users who access once per quarter is very different from 50,000 active users.  Look for comparisons between named users and concurrent users.
2. Transaction Volume.  ECRM systems can place significant performance demands on the databases, servers, and networks.  The single biggest technical factor for company-to-company comparisons is almost always transaction volumes.  Be sure to count both capture and retrieval.
3. Business Case.  The reasons behind the project often dictate certain decisions and play a key role in how the system is implemented and accepted by the users.  Is the system being implemented for an efficiency gain, reduction in legal costs/liability, or as a way to gain a competitive edge in the market.  Great lessons can be learned from organizations who are addressing the same macro business case needs.
4. Culture.  You might have a 200 user pilot in your early stage internet company but that isn’t going to be a good comparison to a 200-user life insurance underwriting group.  Transaction volumes, architecture, and the business needs may be nearly identical, but organizations have their own specific ways to address things.  Look for organizations that have similar employee profiles and industries at the same level of maturity as your own.
5. Distributed Environment.  If you are looking at a multi-location operation, pay particular attention to the various WAN topologies and information flow when making comparisons.  Dramatic differences in performance can be achieved with different approaches.  An organization that has a different Distributed Environment can still be a worthy case study or site visit, but be sure to look for the differences so you can extrapolate for your own needs.

Ironically product choices are probably less important than people think, in part because the above issues limit the potential products and those products have similar architectural and functional capabilities.  When implementing OpenText, for example, you can still gain meaningful results from examination of a FileNet shop, but less so when looking at, say, a SaaS play like SpringCM.