Tricks with Clicks and Bricks

Akin to the many-headed Hydra of yore, banks present many faces to consumers and businesses. There are branches, call centers, mail centers, ATMs, online banking sites, remote deposit options, mobile applications, and others that are perhaps being crafted by the merchants of finesse in our institutions.

The quest for a cohesive multi-channel strategy has been an odyssey almost as long as Homer's celebrated voyage. Yet, one hopes that, unlike Odysseus, we don't end up alone, washed up on a beach in Ithaca! A lot has been written on the barriers to the holy grail- old systems, failed CRM initiatives, inadequate employee training, missing incentives, ad nauseam. I wonder, though, whether the fundamental issue is a tussle between two important strategic imperatives.

In their excellent, but slightly dated book, The Discipline of Market Leaders, Tracy and Wiersma define value as the intersection of three imperatives:

Operational Excellence, Customer Intimacy and Product Leadership. There are few organizations (perhaps none) that are excellent in all three dimensions. They generally tilt in one dominant direction, with the others playing supporting roles.

In retail banking, Operational Excellence and Customer Intimacy pull in opposite directions. Many institutions built branches to be points of high-touch service, driven by a Customer Intimacy paradigm. But branches are expensive to build and maintain. When viewed through an Operational Excellence lens, the fully loaded cost per branch transaction is significantly higher than ATM, online, and remote deposit transactions. Thus, the soft benefits of personalized service (assuming that it exists in branches in the first place) are unlikely to win spreadsheet wars in institutions driven by an Operational Excellence mindset. It is not clear whether institutions really want customers to visit branches, or whether they would be happy if all interaction moved magically from bricks to clicks.

The challenge is not unlike that faced by retailers that also have an online presence. Yet, many of them seem to maintain the balance between driving foot traffic to their stores and maintaining an online presence. To realize how effective cross selling can be, think of the last time you walked into a store to buy shoes and came out with that tie you really did not need. However, we struggle with cross selling in banking. Is it because these retailers are clear in their driving imperative, while financial institutions are torn between efficiency and service?

Odysseus filled his crew's ears with beeswax so that they would not be lured by the sirens' songs to certain death. We do not have the luxury of simple avenues to clarity. How do you think retail bankers should reconcile the tension between Operational Efficiency and Customer Intimacy? Let me know what you think.

(Fr)agile Software Development

Much of our world is made possible by software. There are myriad software systems that manage and move our money, keep track of our health histories, light our homes and offices, and indeed even enable you to read this post. While the sheer scale of accomplishment from zeros and ones flitting about at the speed of light is astounding, the manner in which some of these systems are developed, tested, and delivered raises a few questions.

Over the falls in a barrel. The early years of evolution in software development owed much to needs of the defense and aerospace industries. These were highly mission-critical systems that had to work correctly almost ten times out of ten. A linear process that involved detailed specifications, technical designs, strict coding discipline, reviews, and rigorous testing ensured the delivery of many high performance systems.

A version of this made its way into the commercial marketplace under the broad "waterfall process" moniker. The series of hand-offs, from product management, to architecture, design, development and testing, with intermediate review cycles, hearkened a series of waterfalls as in a cataract. While the process worked well for the most part, it lacked speed. The many steps limited organizations to one or two releases to the marketplace a year. It was difficult to nimbly respond to competitive and regulatory changes. If changes were not included early enough in the cycle, it was tantamount to missing an exit on a tollway, and waiting for the next one.

Sprints around the racetrack. In the 1970's, the automotive industry introduced the concept of "simultaneous engineering", where design engineers, manufacturing engineers, and quality control worked together in teams. As opposed to the linear, "throw it over the transom" model, this engendered both speed and sharing of ideas. That germ of an idea made its way into software as Agile Development. While there are many agile methodologies, the general concept is that specifiers, programmers, and testers work together in short, iterative, "sprints" to produce executable software. Over multiple sprints, complete, ready-to-release applications can be built.

Lost in translation. While agile development has made it possible to release software more frequently, a few challenges have appeared on the way to nirvana. To the agile purists, I will grant that many of these have to do with incorrect interpretation and implementation, and perhaps not because of fundamental drawbacks in the methodologies. The challenges are amplified when you add offshore development where the advantage of co-located teams disappears. They are also most acute when software is developed for General Availability to a large and varied customer base, as opposed to internal use within an enterprise. Here are some of the pitfalls I have observed over the years:

What we have here is a failure to communicate. With apologies to "Cool Hand Luke", one of the main complaints I have seen is, "We don't know what is coming, and when!" We have moved from exhaustive, written requirements to writing nothing down. The refrain is that the sprint teams communicate with each other, and are on top of release content. Some will add that everything can be discerned from documentation within the code. The problem is that there are many stakeholders outside the sprint team, such as sales, marketing, professional services, and support. These people are not adept at reading code, and think in terms of functions and applications, as opposed to individual features. The result often is that market facing groups either oversell or undersell the product (more often the former!).

Who's on first? While sprint teams are cohesive and democratic, the flip side is that it can result in no one at the helm. While the methodologies call for a "function customer" who signs off on software content and quality, this role is often missing in action. Either the role is completely absent, or it is relegated to a Product Manager who is more of a Product Marketer than someone who can go head-to-head with a technician. In the absence of this key role, many cooks jump in to influence the software broth in one direction or the other, resulting in content churn. The process is agile yes, but highly unstable.

Tried and tested. Agile methodologies like test driven development put testing and quality at the center of the process. In practice, however, quality often ends up getting the short end of the stick. The very expectation of agility can compress timelines due to unrealistic promises made to customers. In the rush to "get it out of the door", thorough testing is skipped, and some vendors essentially do their quality assurance on the customer's dime, by continuously band-aiding software at the customer site until it works. In extreme cases, this becomes a license to hack with little regard to version control, belying the very concept of "General Availability". While poor quality is not limited to agile methods, the less rigid process restrictions can exacerbate the tendency in organizations that already have a culture of treating quality lightly.

Customs and traditions. In organizations that cater to customers of varied sizes, the concept of General Availability can be turned on its head. There is often the case of a large customer that wants software customized to meet a unique need. There are very few vendors that have the discipline to examine whether that particular capability warrants inclusion in the software delivered to the general marketplace. The path of least resistance is to include it as a base capability that is "configurable". Over time, the preponderance of configurable customizations makes the software incredibly difficult to implement and support. Again, the lack of a process to adjudicate the "base versus custom" question can result in a multi-headed Hydra, with hidden heads that can appear to bite you when you least expect it.

Distant shores. Every one of the problems discussed explode in complexity when offshore development is involved. The communication challenge now includes time zones, national cultures, and language. The concept of sprint teams working in iterations is predicated on the concept of co-located personnel who can discuss, white-board, and resolve questions face-to-face. Getting this done with people somewhere else on the planet is very difficult, and contributes to hidden costs in offshore development that can obliterate the wage differential in the early stages of the offshore journey. The challenge can be overcome, but it takes special focus and attention to drive out the inefficiencies.

Brave new world. The benefits of agile development have ensured that it is here to stay in most environments. The word to the wise is that getting it to work right involves recognizing the pitfalls, and addressing them involving the right stakeholders. I would not be surprised if many of you recognized your organizations in some of the challenges I have outlined. It is important to recognize that getting software development to work is not just the purview of the programmers alone. Someone said, "War is too important to be left to the generals". If you'll allow the stretch, let me end by saying, "Software is too important to be left to programmers, and methodologies".

Why can't Tellers be Sellers?

Stepping into a debate that is as old as retail banking is perhaps unwise. There are passionate adherents ranged on both sides of the question. To some, the issue is not whether, but should tellers be sellers?

The question brings the raison d'etre of the retail branch network into sharp relief. Are branches retail storefronts with the primary mission to enhance customer relationships, or are they collection points for myriad transactions processed by centralized back office operations centers? Is the driving imperative one of customer intimacy, or does operational efficiency rule the roost?
A tilt towards operational efficiency has traditionally driven retail banking, with occasional overtures to the selling side of the equation. These overtures, however, tend to be fleeting, and with few exceptions, have not survived beyond some concerted marketing and employee incentive programs.

To understand why the push towards serving and selling the customer has not been sustainable, consider a few points. Making check deposits is by far the main reason customers visit a branch. When they do visit, the teller is the person they most often interact with. Regardless of all the training and incentives that may have been put in place, consider what tellers actually do. They are heads down punching numbers into keyboards (try counting the number of teller keystrokes the next time you're in a branch). They have barely enough time to complete the data entry and squeeze out a quick thank you before the next customer is at their window. Imagine a Neimann Marcus salesperson wordlessly packing what you've picked out and intently ensuring that the bow on the package is just right! Yes, the analogy is not quite right- but you get the picture.
So despite many a marketing push, it is the fundamental transaction tether that yanks the teller back into the role of a frontline operations clerk- the first cog in the vast infrastructure that we put in place to process paper checks, featuring planes, trains, automobiles and giant "paper factories".

There is an alternative, courtesy the legislative cover of Check 21 and advances in imaging and recognition technology. Teller Capture allows the teller to drop the entire deposit into a small foot print scanner and interact heads up with the customer, while an imaging application reads all the necessary information, ensures the transaction is balanced, and prints out a receipt when done. Teller Capture eliminates teller induced data entry errors, and also catches math errors up front. This "ready-to-post" transaction at the very beginning of the deposit stream results in major efficiency savings further down the value chain. It is as close to straight-through-processing as one can get in the check world.

"Not so fast," say some. "You want to make my tellers into check operators?" The reality is that the opposite is true. There is now evidence of major savings in teller time per deposit, including data from a Top 5 U.S. bank of having reduced keystrokes from 75 to 5!

"What about the cost of a scanner and software at every station?" challenge others. "It is really difficult to integrate these capture applications with teller systems." The cost per node for both hardware and software is steadily declining, making it well worth the while to examine the return on investment. The hard numbers on transportation savings, back office labor elimination, and funds availability make it interesting- leave alone the soft benefits in customer service and added sales. Capture systems are also increasingly being integrated into teller systems, both by teller vendors that have acquired check-capture technology, and pure play check imaging vendors that have certified their applications with leading teller vendors.

Coming back to the tellers-to-sellers paradigm, what do you do with the saved time? Do you use it to push even more transactions through? Do you have tellers refer customers to other branch personnel based on prompts from an integrated CRM system? Or do you have tellers take on more of a sales and service role themselves? Those are decisions that will be driven by your overarching strategic intent. Do you want tellers to be sellers in the first place? As you ponder that question, you may want to look at teller capture as an opportunity to cut the transaction tether that keeps pulling you back, yo-yo-like, to the paper factory of another era.

India- the new mobile frontier?

I just returned from India. The contrast between frenetic growth in the subcontinent and recession blues in the West is palpable. To be sure, India went through a mild downturn late last year. There was a slowdown in retailing, real estate prices came down a bit from speculatory madness, food prices skyrocketed and annual salary increases in the IT services sector came down to 7% and 10% from the 20's, 30's and beyond. But it is back to growth again for a billion plus Indians- in the number of automobiles, new highways and metros under construction, high rise buildings, and mobile phones.

With 500 million hand sets in use, India has more mobile phones than any country except China. It is adding to that base at a rate of around 35 million phones per quarter! Significantly, 92% of all phones are wireless- a clear indication that the country is leap-frogging the land line era. This in a country where in the not so distant past, a land line required a deposit payment and a waiting period of months (sometimes years) to get!

The phenomenon has benefited from a policy decision to open the industry to private sector competition, as opposed to domination by state owned monopolies as was the case with the wireline industry at the outset. Fierce competition has driven prices down to the point where many at the "bottom of the pyramid" can afford the service (BTW, C.K. Prahalad's book on the fortune at the bottom of the pyramid is a great read). Incoming calls and texts are free, encouraging consumer use, as well as businesses hawking all manner of products and services direct to the handset. Tata Docomo recently introduced a pay by second model at one paisa (about 0.022 cents) per second, which is bound to boost call volume.

In addition to mobile marketing, there are other mobile services that are poised to avail of the critical mass and growth in teledensity. Mobile banking is one area where we may very well see India leap-frog other countries. While only 1% to 2% of mobile subscribers use mobile banking services today, there is an enormous upside. Some of the common uses today are bill payments, insurance premiums, charitable donations, pre-paid mobile telephone recharging, and travel ticketing.

The Reserve Bank of India (RBI) has been both aggressive and strategic in building a regulatory framework to enable the growth of mobile banking. It issued guidelines for Mobile Banking Transactions in October 2008 addressing banking, money transfer, payments and commerce. RBI has since moved to swiftly revise some aspects of this guideline based on feedback over 12 months.

Arguably, the most well known example of mobile banking in the developing world is M-PESA in Kenya. It is widely used for money transfer by the unbanked and is run by the mobile operator Safaricom through a nationwide agent network. The RBI, however, wants banks firmly ensconced in the transaction stream, but with a twist. While funds have to be deposited at a bank branch, the disbursement of cash at the receiving end can be through an ATM or a bank-appointed agent. The RBI is thus ensuring the need for oversight through Know Your Customer (KYC) norms and the regulated banking system to address money laundering concerns in a part of the world where informal networks like "hawala" are rampant. It is also addressing the need for "last mile convenience" in a country with an evolving physical infrastructure. The not so invisible hand here is that of the RBI, nudging banks, mobile operators, and others with agent networks to partner to facilitate ubiquity and security.

Other RBI modifications include raising the daily cap on transactions from Rs. 10,000 (~$218) to Rs. 50,000 (~$1087), enabling larger purchases, such as airline tickets. At the other end of the spectrum, it also removed the need for end-to-end encryption for transaction below Rs.1000 (~$22) to remove the cost overhead on small transactions.

While the stage appears set for an upsurge in mobile transactions, led perhaps by funds transfers from banked urban workers to families living in villages, it is not easy to pick early winners in the race. Of the 32 RBI approved mobile service provider banks, 21 have launched services. The partnerships between banks and mobile service providers are yet to materialize. While India is known for its information technology prowess, most well known names are services companies. There are very few true product companies in the country that have embraced product management, development and delivery for general availability, and streamlined delivery and support of versioned products across large customer bases. That would spell opportunity for the many battle tested mobile banking product vendors in the U.S. and Europe, right?

Well, before you pack your bags for Mumbai, keep in mind that selling software into India is extremely challenging. Markets at the bottom of the pyramid are very price sensitive. They call for innovative price packaging like the one paisa per second model from Tata Docomo. In addition, while attitudes are changing, justifying value for software products in India is difficult. Races to the price bottom, regardless of other value attributes, are common. If your business model dictates recovery of Dollar or Euro based cost from Rupee sales, you can end up in a bind if you are not careful.

Despite the cautionary note, mobile services in general and mobile banking in particular are poised for explosive growth in India. We will see innovative services offered there before we see them in the West. It is a transformational journey of a billion people that will be exciting to watch and participate in. Mumbai, anyone?