Banking

Innovation and the idea approval index

  • Wednesday, 28 November, 2007
  • By:

I’ve written in the past about organisations setting up test and learn capabilities, and how languages such as Ruby on Rails make this so much easier. Sadly, even with the best will in the world it is not unusual for these internal skunk works outfits to fail. Scott Berkun’s recent post gives a good reason why; they score highly on the Idea Approval Index where the higher the number, the harder the innovation is.

If you are going to be serious about test and learn it is essential to remove barriers to its success, and that means removing bands of bureaucracy and sign-off. Identify the number of approvals you assume will be required then plan how to eliminate them. What strategies can you put in place to keep stakeholders in the loop, but at a distance so they can’t kill the innovation before it’s given oxygen to breathe. Realise that what is being tested is a “beta” and market it as such. Give clear terms and conditions, use controlled environments (for example testing on staff within the internal network), anything to prevent it being subject to the usual legal / compliance / architectural constraints.

Small shops do themselves no favours

  • Tuesday, 13 November, 2007
  • By:

Walk around London and it’s hard to miss the Maestro “Cash Is Dead” advertising campaign. You’d never believe this in many small bricks and mortar retailers; try to purchase something with a card for say £7.99, pull out the plastic and the shop keeper shakes his head and points to the sign – “no card payments for under £10”. What sort of madness is this that retailers refuse to accept money because it is the wrong sort of money?

OK, so there are interchange fees; a card payment is probably going to incur a charge of around 2% of the transaction. For the retailer there is therefore an incentive to prefer cash. But at what cost? (Perversely for the banks they penalise against not using cash, despite the handling for cash being so much more than an electronic transaction).

Let’s say I am buying something for £7.99. Let’s say the cost price for the item is £3.50. That’s £4.49 gross profit. Obviously this doesn’t all go into the retailers pocket; the tax man takes his share in VAT and there are the operating costs. I’m no retailer, but let’s assume that a whopping 90% of the gross pocket is swallowed up in costs, leaving the retailer 45 pence net profit. Now of this, the bank is going to take 15 pence from the retailer for me using my card. Which the retailer is not happy about.

And this is the mad part; for the sake of 15p the retailer is willing to loose the sale (OK, that is 36% of his net profit – and that is a lot, but isn’t cash flow king?). He has given me a shocking customer experience, not allowing me to buy from him this time (and I’ve got a memory – not going there again). I’ll go down the road to the supermarket where they will not only accept my card – but give me cashback as well!

There is of course, an alternative. Give the customer an option of using the card, passing on the card fee. For most customers, the opportunity cost of paying slightly more but getting instant gratification is probably more acceptable than either driving several miles out to the supermarket, or having to find a local ATM.

Unleashing innovation at speed

  • Monday, 29 October, 2007
  • By:

It sounds clichéd and old hat, but it is true. Truer now than ever before; the web is an enabler for new ideas. It provides you with the tools for disruptive innovation. Sadly for too many organisations it has become a hindrance.

A recurring theme with many organisations is the length of time it takes to take an idea to market. Especially in retail financial services, where you would expect lead times to be short it is not unusual for innovations to take a year to implement. This seems crazy, it’s not as if there is a physical product to manufactured.

So where are the hold ups? More often than not, they are rooted in the organisational structure. Innovative products often cross business boundaries; whilst customers only see the a single brand, different product teams only see what they are responsible for. They have own objectives that often conflict with other parts of the business; gaining agreement and consensus across all parties can often be a time consuming and painful experience that slows and often kills innovation.

Then there is the technology. Changes to systems have to be scheduled (along with every other request). Unproven ideas are put to the back of the queue. The business starts to perceive IT as a hindrance rather than an enabler and lines of conflict are drawn up.

Channel is the next hurdle to cross. Typically a face to face channel or telephony will be easiest, but getting something on the web? Now a new area of the business needs to be involved, the Internet Channel Team who interface between the business and IT. They’ve got to design web pages, get the creative done, produce requirements for technology to build (and schedule into deployment for which the dates are even further into the future), do usability testing… Long lead times are inevitable.

And then, before the innovation sees the light of day, someone new comes in to rationalise the product portfolio, the innovation doesn’t quite fit in with their new priorities and it is quietly ditched. This half hearted attempt at innovation has taken a year, cost in excess of a million and has come to nothing.

There has to be a better way.

There is. Do things at speed. You can start by sticking some amphetamines into ideation phase. Someone’s got an idea; identify who has a vested interest in it succeeding (or failing) and get them into a room to thrash it out. This doesn’t need to take long. Workshops are best limited to 90 minutes at a time (after that people get Blackberry withdrawal symptoms and loose interest). But if all the stakeholders are geographically dispersed, a structured day’s off-site might be the best solution. Avoid letting people dial in or video conference, this is one meeting where people have to be there in physical presence. Also avoid having too many people in the room, especially when forming ideas (there is a trade-off between having the right people and too many people to make the process unmanageable). Start with the users, the customers, the people whose lives will be changed by the idea. Scribble out personas -describe who they are, what their goals are, the perceptions of your company, of technology. Print out pictures of people that represent the personas, rip out photos from magazines, anything to bring them to life. As the idea takes shape, turn it into pictures. Draw out the customer experience. What would the persona do at each stage. Far better to do this than write it down in a document that can be open to interpretation. Illustrate the touch points. What does technology need to do. (Can we be pragmatic and use roller skate implementation rather than getting bogged down in an integration quagmire?)

Now is where it gets interesting. There once was a time when you would need to invest time and money into producing a heavyweight business model and business case for the innovation. You still need a business case, but at this stage it probably doesn’t need to be too robust; make some basic assumptions then test it. All too often business cases are built on flaky assumptions; build something quick, test it and get real data to build your models on. Again, this is about doing things at speed; a couple of weeks after the first workshop there is no reason why a small team of developers can’t be actually building something to bring the idea to life. So the team is using Ruby on Rails to build a proof of concept. There may be disquiet that this doesn’t fit into the current technology stack – doesn’t matter, it is a proof of concept. Six weeks later the proof of concept is done. It is not a static, prototype that demonstrates linear page flows, it is fully featured and fully functional. It can be usability tested (but more likely you were doing that on wire frames alongside the build). What then? In two months you’ve taken your idea and turned it into something tangible.

Why not put it into the market for real. Whilst IT might not want this Ruby “thing” on their stack, that doesn’t mean it isn’t possible and can’t be done. Large organisations have a testing ground of consumers inside a secure environment – their staff. Use them to beta pilot the idea? Friendly customers are delighted to be part of product development – put it out to a small and selected group of customers, and have some smoke and mirrors processes to handle fulfilment. The objective is to prove the viability of the idea, get data to make informed decisions and make your collective mind up quickly. To fail fast or succeed cheaply.

Confirmation – undo

  • Monday, 22 October, 2007
  • By:

The traditional pattern for the on-line banking “make a payment” GUI is:

  • What you are about to do (text)
  • Select “From account”
  • Select / enter “To account” (Beneficary)
  • Enter Amount
  • (Optional) enter “when” (you want payment to be made
  • Confirmation (“you are about to pay this amount from this account to that account. Are you sure?”)
  • Post process confirmation (“You have paid this amount to that account from this account”)

So here is a question. Are those confirmation screens really necessary. What if you made your payment, hit the “OK, make the payment” button and it is done. An alert appears (like when you do something with google) that says what you have just done with an “undo” call to action (“I’ve made a mistake, I don’t actually want to make that payment afterall”). The assumption there is that the user knows what they are doing – we assume a happy path with the opportunity to go back rather than placing “confirmation” barriers to completion which are probably unread anyway. There will be considerations of when the payment is actually made; does it hit the clearing systems when the user hits the pay button (not that it ever does anyway). Does the undo option disapear after a period of time (i.e. five minutes), or when the user navigates away from the page the alert appears? But let’s leave the implementation to one side.

I like the idea of undo instead of confirmation. However, I have a hunch that it will not fly when we show it to customers, because people are so ingrained with the “confirmation” dialog. I’m waiting for the response “I’m not sure I like that” from customers who use the current website, because it different, unexpected and is wholly inconsistent with what they have today. But what they have to day is based upon legacy technology and the immaturity of the platform.

So a suggestion. Let people undo. Tell them what they’ve done after they’ve done it (positive feedback), with the opportunity (in the banking environment in a time boxed period) to rectify their errors or change their minds. Do away with confirmation dialogs. Everywhere. (Do you want to save this document? – instinctively I say “no”. It is only later that I realise my mistake…) Here’s to a web that places minimal barriers to task completion.

What is your business

  • Tuesday, 31 July, 2007
  • By:

Should “the business” care about IT? Should an investment bank trader know anything about XML, or a marketer know anything about SQL? Probably not. Even less so should they be talking to their IT colleagues of their requirements in these terms. The business should speak to IT in a language of value driven requirements rather than implementation detail. What is the outcome you need or want, not how you think IT should deliver or implement it.

Yet in many organisations (especially where IT has historically had a track record of failure), the business has taken a greater interest in IT delivery. They start talking the language of the techie. When this starts to happen business operations no longer see the clarity of their business. They see systems. In an investment bank setting: the trade is booked in Zeus, settlements are handled by Minotaur, payments by Socrates. Corporate actions are handled in Hades. Depending upon the geographic region, client management might be handled by Tomsys, Dicksys or Harrysys. You ask a business person what do they do and they talk in terms of systems. Getting down to the underlying requirements of what they actually want to do is hard. Innovation and creative thinking are hard because they always return to what the limitations of the current systems are. They focus upon the requirement for a Reconciliation System rather than asking why there needs to be any reconciliation in the first place.

So here’s a suggestion. Act dumb. Forget everything you know about the way you do things and go back to first principles. How would things be if we were starting from scratch? How would you describe your business intent (not the what you do now, rather what outcomes you really want to achieve) in simple terms to a complete novice. I doubt the word “system” would come into the description.

How to loose your customers

  • Monday, 9 July, 2007
  • By:

Last year, Barclays offered a fairly compelling home insurance proposition. They beat your current deal by £50. A friend took advantage of this offer. A year later they sent the renewal documents through. Being a reasonably busy and disorganised guy, he never got round to renewing the insurance until six weeks after it had expired. He rang the call centre explaining that he wanted to renew; yes, he had been without insurance for the past six weeks, but wanted to take advantage of the premium they had quoted. But Barclays refused to honour the renewal quotation. They told him that as the policy was not continuous he would be treated as a new customer. The policy he was now being quoted was significantly more than on the renewal letter. He asked to speak to a manager and was again told the renewal quote was no longer available.

So he went to Money Supermarket and got a competitive deal from Halifax. Indeed it was much more competitive; five times cheaper than the Barclays call centre was offering.

So despite all the cost of acquisition, Barclays were quite happy to loose an otherwise loyal customer who was prepared to pay their original quotation. They then gave him good reason to shop around and have now lost him for good.

If there is a moral in this story, it is when developing new products, propositions or supporting technology, play out all potential scenarios. Customers are not always rational beings, they don’t always behave in the way you assume they will. Don’t just design for the “happy path”, but challenge your thinking with “what if” scenarios for what happens in the real world outside your idealised customer model.

Banking hasn’t moved on

  • Monday, 2 July, 2007
  • By:

My Great grandfather worked in a bank. He probably witnessed the introduction of the adding machine. Even then his work life would have revolved around the quill and ink; double entry book keeping, maintaining the accounts in journals and ledgers. In those days they were real journals and ledgers. And in balancing the books he would be reconciling data from one paper record to another.

Almost 100 years later and I recently found myself working for a bank… And I’m talking to people whose work lives, like my Great Grandfather’s, revolve around journals and ledgers. Only now their adding machines and the books have been replaced by systems.

Yet 100 years later their jobs remain similar to my Great Grandfathers. They are still reconciling data from one paper record to another. But it is no longer the journals themselves they are reconciling; now they are reconciling printouts of excel spreadsheets.

If IT was supposed to automate banking processes, take away “human error” and do away with reconciliation differences, IT professionals have failed to deliver on the promise. Indeed they’ve made things worse. The books may balance in one system, but add a few more systems, across the globe then things go a bit 1910. Manual reconciliation is still someone’s day job. It’s a sad fact that banking hasn’t really moved on in all that time.

What is your business?

  • Monday, 18 June, 2007
  • By:

Should “the business” care about IT? Should an investment bank trader know anything about XML, or a marketeer know anything about SQL? Probably not. Even less so should they be talking to their IT colleagues of their requirements in these terms. The business should speak to IT in a language of value driven requirements rather than implementation detail. Yet in many organisations (where IT has historically had a track record of failure), the business has taken a greater interest in IT delivery. They start talking the language of the techie. When this starts to happen business operations no longer see the clarity of their business. They see systems. In an investment bank setting: the trade is booked in Zeus. Settlements are handled by Minotaur, payments by Socrates. Corporate actions are handled in Hades. Depending upon the geographic region, client management might be handled by Tomsys, Dicksys or Harrysys. You ask a business person what do they do and they talk in terms of systems. Getting down to the underlying requirements of what they actually want to do is hard. Innovation and creative thinking are hard because we always return to what the limitations of the current systems are. Why there is a requirement for a Reconciliation System rather than asking why there needs to be any reconciliation in the first place.

So here’s a suggestion. Act dumb. Forget everything you know about the way you do things and go back to first principles. How would things be if we were starting from scratch. How would you describe your business intent (not the what you do now, rather what would you do) if you had to explain it to a novice who was starting a competitive business to put your business out of business. I doubt the word system would come into the description.

The little things really do count

  • Thursday, 14 June, 2007
  • By:

Ever since I saw Joe Walnes demonstrate it, every project that I find myself on which has a search requirement, it is never long before I am trying to convince the team that a “find as you type” search mechanism is the way to go. Usually everyone is in agreement, but occaisionally stakeholders try and de-scope it saying it is low priority “gold plating”.

Now look at the way that google finance and yahoo finance handle their stock ticker search. Over time, tell me which one you would prefer to use? Tell me that the Google search is just “gold plating”.
It gets worse for Yahoo; they treat tickers and stock names seperately, requiring different searches. As The Stawart states “the fact that Yahoo has its ticker search and its name search in separate boxes, after all this time, seems downright negligent.“

Swivel chair integration?

  • Wednesday, 18 April, 2007
  • By:

Liverpool Victoria website - quotes only available at selected times

One of the great promises of the eCommerce was that goods and services are always available, 24/7.  Not apparently at Liverpool Victoria whose online quotations are only available at selected times:

Please note that our online car insurance quotes are only available at selected times: 8am to 11.45pm Mon-Fri, 8am to 3.45pm Sat.

One can only assume that this is an issue with their integration of their website with their backend quotation engine.  Was the quotation engine built in the days of 9-5 business and is unavailable outside business hours?  Maybe it depends upon overnight batch processes that render it inoperational between 11.45 to 08:00 and from 3.45 on Saturdays to Monday morning?  Or is this swivel chair integration, some poor soul manually taking requests from the web site and entering them into the legacy system?  Someone who doesn’t work nights, Sundays and whose weekend starts at 3.45 on Saturday?

3 of 4
1234