I have a statue of an elephant on my office credenza. It is actually an exotic little contraption, a bank, where a coin placed on its spring-loaded trunk will be deposited in the elephant.  It was a gift to me from a consultant friend of mine, after I told him about my experience with a number of major financial software conversions. Dealing with the fallout from system conversions, I explained, is like cleaning up after elephants (after recalling an incident I had witnessed involving some poor photographer at the Brookfield Zoo…). Next time, I promised, I was going to get in FRONT of the elephant. 

The Wall Street Journal today reports the slogan “One Line Of Code” in its description of the massive software failure at Knight Capital Group, which resulted in nearly a half billion dollars worth of losses and the collapse of a central player in the equities market.  This could well be the mantra, however, for any major system change involving retirement plan systems as well.  
Think about it. Retirement plans, and all of their moving pieces (from CRM, to compliance, to trading, to financial transactions and everything in between) likely create some of the most complex of transactional requirements that exist in the financial marketplace. Hedge fund and other trading platforms have complex formulas, for sure. But if you take a retirement plan from soup to nuts, with all of its different iterations, you’ll likely not find a set of processes in the financial marketplace that has more massive and demanding systems requirements.
The problem Knight had is really one that has (usually quietly) been encountered by most major financial service firms in the retirement market, and has been outrageously expensive for those firms. The challenge is what I call the “overpromise of technology.” The IT executive or consultant of an organization makes grand promises to the business side of the house based upon grand conceptual notions, all of which-by the way-make great sense on paper. These notions can be made to sound so very enticing. But the problem is that the executives generally underplay one very basic tenant of software development painfully driven into to me by some very talented developers: software and computers are dumb.   They will only do what you tell them to do, and at a very granular level. 
The “grand notion” may be great on paper, but-particularly in the retirement world-the very close details, the minutiae of which I have often spoken of in this blog, is what will make or break any such effort.  The “80%” rule won’t work; you have to worry the details.  It is the smallest of choices which will trip up the viability of any system development effort. What makes this so counterintuitive to the executive is that properly managing this risk means putting some very high level and valuable corporate assets into the “grunge pit,” grinding through the thousands of small decisions that must be made in the development of software which are really reflective of corporate decisions about how you will run the business. It is painful. It is time consuming. It is ugly. It is exhausting. But it is the ONLY way a system can be properly developed in a way that serves the business, and delivers on the promise. But this is a lesson far too often lost in the C-Suite.