Define AD Department please
For the purposes of this article the AD department consists of the change introduction and IT project resources. These can be in-house or outsourced. It does not include the IT operations function, nor any back office processing. For a big UK bank this represents between £200m and £500m per annum of cash flow, mostly in the form of operating expense although some of it may get capitalised. Big UK banks have been running AD departments of this size for at least a decade and in most cases nearer 20 years.
Big Banks are not unproductive!
Well actually for AD they are. We cite two indicators:
- Smaller banks have achieved the same level of IT coverage with much smaller AD resources. In the UK banks like Nationwide Building Society, RBOS and BOS (before their mergers) had much the same IT coverage as big UK groups with massively smaller AD departments. Similarly Banco Popular (at one time the most profitable bank in the world) and Banc Sabadell have the same coverage as the much larger BBV and BSCH in Spain. There are clearly great economies of scale to be had in IT operations, back office processing and branch rationalisation but there is no such evidence for AD department economies of scale, rather the reverse.
- In the mid nineties the author was working with the Gartner Group on IT department benchmarking studies and the methodology estimated the number of function points produced per man year of AD department resource and per dollar of AD department cost. Both figures in big banks were extremely low by any standards, for example 10 to 30 function points per man year.
Why is this?
We believe it is nothing to do with IT technologies and methodologies. Big banks have all tried everything. They have tried all of 4-GL’s, object orientation, RUP, UML, package software, relational databases, project management methodologies, end user programming, web services, XML, Six Sigma, client server, mini computers, AI, data modelling, Zachman frameworks, etc, etc. These all make contributions to improving the department and staff development but have not made any significant dents in the lack of productivity in big banks. We think there are two distinguishing factors of such organisations in the context of AD.
- User plurality and rights of veto
- Too much parallel change on one infrastructure
User Plurality and Rights of Veto
Big banks, because of their scale have a very high division of labour. For example a credit management department in a division of a small bank might be one department. It would probably consist of the following departments in a big bank:
- Credit Policy
- Credit Operations
- Security Operations
- Credit Information
- Credit ‘Intensive’ Care
- Recoveries
Furthermore, each of these departments might reasonably expect full involvement including sign off rights to any credit system changes.
Lots of large organisations have a division of responsibilities/skills but what makes big banks unique is the combination of these divisions with the commonality of the IT infrastructure. The best analogy we can think of is that if Ford:
- had one manufacturing plant for all its product lines,
- that the plant were to manufacture all components and sub assemblies as well as finished products,
- and that the distribution were done entirely in-house in a tightly integrated, automated way (eg via driverless monorail straight off the production lines).
In this unreal situation there would be big bank comparable difficulties at Ford about any change to be made to production systems, because so many Ford departments would be involved.
In practice this does not happen at Ford because the infrastructure is more disaggregated. It is the essence of the (highly successful) banking business model that there is a very high degree of sharing of components (both business and IT) across multiple customer and product sets. The consequence is that it is common to see requirements documents with sixty or seventy departments in the sign off list. This plurality of users with veto rights is much worse in big banks than practically anywhere else. This does not stop with requirements either, every change request, test result, implementation plan etc, is subject to the multitude of user interests.
Too much parallel change on one infrastructure
The smaller banks have traditionally had less financial capacity instigate change projects and to develop systems. In absolute terms their business cases could only justify AD project spend of a certain size and the collective spend was limited by the overall investment capacity of the small banks. With big banks these financial constraints all but disappear and so big banks attempt more projects in parallel, all with good business cases. However, the yield curve with increasing AD activity looks like the diagram below.
Where the droop of the curve becomes noticeable is not something that is easy to gauge and so its position in the graph above is purely to illustrate an effect, it may well kick in at the 500 staff level. However, for a typical UK bank, with an AD department of a 1,000 people or more, a 30% increase in investment almost certainly does not give 30% extra delivered code; it probably only gives about 5% extra code. In essence this is caused by multiple parallel projects having to continuously check with each other on a variety of aspects such as data definitions, infrastructure software levels, interface standards, integration test resources, user training plans and so on. As the number of projects in parallel increases, the degree of inter project communications required increases exponentially. For a more detailed illustration of this point see the appendix.
What can be done about this?
(A) User plurarilty and rights of veto – this is fixable
Senior business managers can make a major difference by reducing the amount of stakeholder interaction required in change projects. This will probably require the creation of a new kind of professional which for the purposes of this article we will call a “super-user”. This individual’s role should be a full time one, dedicated to understanding the business processes and the business investment cases/strategy. They are probably an experienced line manager seconded for a year or two at a time and given at least 3 months to train up in the detail of all the different systems and processes. These people should be empowered to make decisions on the nature of the systems to be built and the relative priorities of functions to be developed.
- Are these business project managers? No. They are not expected to manage budgets, hit milestones, build and lead teams. They will need to understand the project environment because some of the factors they will have to trade off when making decisions are things like timescales and costs versus user functionality.
- Are these business analysts? No. Business analysts carry out a variety of tasks to gather requirements, outline solutions, construct tests and help with implementation, but all their work is premised on the assumption that someone else makes the decision, either a business owner or a project manager. The “super user” is a decision maker.
Currently business decisions makers are either project sponsors or system owners. Whichever role they have it is usually a sideline to their proper job of running a business department. They do not have enough time to do the decision making on lots of small parts of system functionality so they get the IT team to circulate a document to the myriad departments and ask the IT team to resolve differences. The IT team are not normally well equipped to do this and so the whole decision making process takes ages. A “super-user” would be an improvement on this provided:
- the ‘super-user’ is trained.
- the ‘super-user’ is empowered.
(B) Too much parallel change on one infrastructure – probably not fixable
This author is somewhat gloomy on this point and thinks there is an upper limit on the size of development staff that can be productively deployed on a bank’s infrastructure and that most AD shops in big banks could be cut quite significantly without much loss of output. Whilst cutting the AD department will not achieve the Bank’s change agenda, it will get some of it done and at less cost.
Many banks have some woolly architectural vision to break up the common infrastructure into loosely connected chunks that can be modified relatively independently, hence reducing the need for inter-project communication and its associated costs. Unfortunately the author believes that big bank systems are integrated in too many ways, for example:
- data definitions and conventions
- shared operations infrastructure and standards
- complex intersystem control dependencies
- user interface and business process level integration
The author believes known methods of separation (e.g. object orientation) only make a small degree of isolation when applied to the banking systems base.
Perhaps the best that can be done is for Business managers to recognize this limit in the IT project portfolio management process and only allow a certain level of spend on the integrated systems. Other investments, quite possibly not so high up the priority list might still be allowed because they organisationally and functionally are a long way from the tightly integrated core, e.g. a stock broking or insurance subsidiary’s back office automation project.
