There has been massive change management taking place across all sectors of British banking over the last three years. Much of this is driven by buy outs and mergers, some by efficiencies and a little more recently through questioning the nature and controls around risk management.
However simply changing the owner has caused major problems in these banks as their competitive advantage and therefore their value has been an amalgam of very different skilled people, internal processes and market penetration from the bank or group buying them. These internal processes have often evolved in a highly organic method through acquisition and proven delivery often driven by individual people. However once this people based relationship is broken and these processes are exposed to a wider audience they pose serious questions in relation to risk management, value and the continuance of revenue flow.
The standard process applied has been to pass these processes over at division level to change program managers, at department level to business analysts to define the scope of the current structure. After definition many of these process based activities are passed over to information technology to resolve. I remember being taught at University (Napier, Edinburgh) that technology should never be used as a substitute to sound business process; however this technology determinant does not seem to have been passed on to banking business people. While not the best starting point, people who work in technology do tend to ask the right questions, to define epic requirements, even when it’s unpopular with the business.
Information technology analysts take these epic requirements and define an A to Z system ‘what it does’. However to get the B to Y user requirements (or stories), a user centred design analyst, ux research and designer spends time with the users to define ‘how it works’. This may seem obvious to digital practitioners outside banking, but it’s a revelation to those inside banking and banking technology, that users who normally find ways around poor software are able to define the requirements that turn a useful application into a killer application.
This is not really the end, more a beginning, if other sectors can learn from banking, that users (not stakeholders, usually no longer active users) can determine the overall success of software. And that user centred design (UCD) can assure and amplify competitive advantage if underwritten by skilled practitioners, then the possibility of success is significantly raised in all software and change programs.