Reducing Complexity with Magic Quadrants in Banking

I’m always amazed at the amount of faith placed in the content of Magic Quadrants. The identification, shortlisting, and selection of solutions based on an arbitrary position in the upper right hand quadrant has become a standard practice and an easy crutch in the “mitigation of risk”. The conviction that I have seen based on quick reviews of vendor names in these quadrants has baffled me for years. Don’t get me wrong, I’m all for using other peoples research and opinions to help form my own. The issue for me is the fanatical belief in the benefit, both functionally and to the enterprise, of one solution over the other based on the assessment of a provider’s vision and ability to execute . In my experience this fanaticism can manifest itself in a couple different ways.

Bells and Whistles

The first is when business users select the highest rightest solution, take the time to understand why it scores higher than the other competitors, then write requirements tailored to these differences instead of actual business needs. This essentially negates the other competitors all together as the business consistently points to those two or three functionalities they don’t share with the highest rightest solution. I call this the bells and whistles mentality. It’s human nature to want the newest, best, shiny thing.

Risk Mitigation for the Masses

In most large organizations, particularly banks, risk identification and mitigation are cornerstones of the culture. In banking this can be taken to the extreme and the mitigation of risk can become the primary value of the organization. What I mean by this is that everyone looks for reasons not to do something because its risky. Due to this many will look to outside sources and industry standards to validate the selection of a solution. This way they have reference-able sources to point to if and when something goes terribly wrong during an initiative. The easiest thing to do to mitigate risk is to blindly select the highest rightest solution. The assumption being that smarter people than you who live and breath this stuff have already weighed in on the topic and your work is done.

Realistic Use of the Quadrant

So how best to use the information in a magic quadrant? Well first look at what the quadrant tells you. It measures two things, ability to execute, and completeness of vision. These are generic to a wide industry and are not specific to your organizations specific environment, business requirements, and culture. The upper right quadrant is a good starting point for creating a short list of possible solutions. Let’s face it if a solution is in the upper right quadrant the provider is obviously doing something right. Finding the right fit for your specific situation, however, requires a little more work, and self assessment than is provided by the magic quadrant.

Short list out of the top right quadrant yes but if you are a bank that has recently adopted a new core banking platform look to see if your core platform provides a module or integrated partner solution that provides the same functionality. If it does, hopefully it is in the upper right quadrant, if it is not do not dismiss it outright. Put it in the mix and assess it against the others. I would then take the short listed solutions and plot them in within your own, organization specific, quadrant classification. For me I would assess on two organization specific axis; ease of integration and total cost of ownership. To help reduce complexity with your bank assessing solutions for ease of integration and total cost of ownership are two of the best indicators.

When solutions are assessed against your own organization using ease of implementation and total cost of ownership a clear vision of complexity will emerge. In this case the quadrant that matters is the upper left with high marks for ease of implementation and a lower total cost of ownership. Granted that the assessment of overall complexity will always need to be weighed against realistic business requirements but assessing complexity in this organization specific type of way will provide a valid comparison of solutions based on organizational realities. It will also provide factual discussion points for IT and business to use during the final decision process.