Karl Smith is a highly competent, personable, creative and motivated person with a keen insight and definition ability. He is a critical thinker and able to rapidly discover the essence of problems then define, communicate, create buy-in and deliver end to end digital and process solutions. He positively motivates those around him and is able to engender a great team dynamic by leading from the front. He has business experience since 1989 at comparable levels in fields including defence, industry, energy, pharmaceutical, biomedical, construction, fashion, finance, banking, FMCG, property, publishing, healthcare, travel, policing, crown office, local and central government. He has specialist banking experience with investment, private, commercial, business, trading, wealth management in Europe, USA, China, Australia, Japan and Russia.
Karl has worked with several companies to define for launch or redefine their service offerings, business structures or digital presence.
Requirements gathering in Banking change programs are over detailed, over long and for the most part undeliverable.
There is and has been a huge requirement for change in British banking for several years as senior bankers have sought to lever the capabilities of technology and distributed workforces. This has in turn a great opportunity for IT consultancies to enforce their business models on the banks and make huge amounts of money without delivering anything. This has of course not gone unnoticed and forced many banks to increase their internal IT teams, but the problem remains, as the overall strategy is wrong.
The current strategy for business change requirements gathering is to fully understand the current problem with the assistance of subject matter experts (SME’s) and then defined the end state with the internal client. There are several major problems with this approach;
Fully understanding the problem is almost endless in Banking
Using SME assumes they really are experts which for the most part they are not
That the internal client can see the future of their business
That the same consultants will carry the project all the way through
The solution to this problem is a new strategy, in fact an Agile based one;
Defining 6 to 10 features of the new system at a high level
Involving the enterprise architects to see what has to be new, legacy or adapted
Launch the development team during the definition phase
Detail the features and get time costs from the designers and developers (not the PM or delivery manager)
Doing the above will change the relationship between requirements and delivery making requirements a service to the delivery of the project rather than an impossible set of promises made by people who will never have to keep them.
The 35% savings is probably low it’s just the 14 months and 35% of a budget wasted on an investment banking project that were eventually discarded. I’m considering a new concept in banking requirements gathering, value for money, is anyone interested?