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?