Compliance is core business

Compliance is a mandatory pain

Most often, compliance projects are perceived as a mandatory pain. The strict minimal effort is spent to comply with what is required by the regulator. Even if those projects are categorized as mandatory, they are not dragging the same kind of attention as revenue generating projects. What matters is that those projects are completed, costing less as possible.

This behavior impacts the way those projects are managed: instead of looking wider, trying to generate value mobilizing best business contributors, those projects are treated in a narrow view, which of course (no magic !) is not bringing any value. Therefore money is spend just for the sake of being compliant.

There is always something positive in a change

It is said that there is always something positive to be found in any change, even in one enforced by regulators. Therefore, one could also find some positive aspects to those mandatory projects which could also bring value and not only costs.

Let's take an example to illustrate what is said above: Business Continuity Plan. This is a mandatory plan that banks have to elaborate and maintain in order to ensure continuity of their businesses in case any type of problem (strike, power outage, flood, IT outage, metropolitan issue).

BCP is rarely a core process

Even if past has unfortunately shown that such worse case scenarios were not science fiction (9.11), putting this in place is still considered as a mandatory pain by many actors.

This attitude reflects in the way those projects are managed: not considered as core, they are often delegated to a team outside the business and communication and mobilization of this theme are pretty poor. The plan is usually quite basic with little value added and testing, which has to be done on a regular basis, is executed poorly, no one fully understanding what is meant to be done.

Stepping back for a while, one could think of positive outcomes coming from a BCP process : a sound BCP process means that the whole company is sustainable, being able to face major problems, and that customers can safely leave their money in their account without risking to loose it or not able to access it anymore. An outstanding BCP plan can be more than a cost; it can also bring a competitive advantage in communicating on this topic internally and externally.

Sustainability should become a key value

Bringing sustainability as a key value for the company means that internal and external communication will include that theme and that BCP projects will become visible not only because they are forced by regulators but also because they become core business. This will generate a stronger involvement from all parties, more ideas, a smarter plan and a better use of resources.

Instead of being seen as separate, those processes becoming core will also transform the way business is operating. An example of thinking more globally could be that instead of having a separate local provider substituting to the original one in case of emergency, one could think of sharing other existing resources located abroad, reshaping the regular process so that daily operations are shared among the two locations. At the end of the day, sustainability and processes are improved, potentially without generating additional costs.

Of course, this is a basic example, just to illustrate the benefit of considering sustainability and compliance more generally not as being aside but part of core business.


Better for the banking industry to anticipate this move as sustainability is more and more becoming a key topic for regulators. The ones making the move first will be the only ones getting benefit from it.

Capital markets IT

An incredible growth

In the last 20 years, the very strong growth on capital market has triggered huge investments. For some companies strategy was pretty straightforward: any product, anywhere! Focus was definitely on growth and not on costs. The priority was to grab new market shares and revenues not to save cost or improve efficiency.

The direct consequence of this strategy has been a huge size increase as shown in the
following graph:

Goldman Sachs employees (Source Goldman Sachs)

Management capacity had to grow accordingly

This growth has not been possible without increasing management capacity. Going on with the Goldman Sachs example, if we consider that a team is composed of an average of 6 teammates, the growth in the graph above correspond to an increase of more than half a hierarchical level!

As experienced managers were not so common within Capital Markets IT, a lot of experienced managers, able to structure teams to sustain this growth have been coming from other industries or even other areas than IT.

Since the crisis, innovation and revenues race is over

The financial crisis is bringing a new situation: growth race is over, cost is the main focus. This is forcing the financial industry to move back cutting costs and jobs. This is where the main challenge is: how to scale down regaining efficiency? Will the managers that have been managing the scale up be able to manage the scale down?

This deep transformation is very difficult to trigger and is coming from top management which, seeing smaller or new competitors entering in the market, may realize that a deep transformation is mandatory. This transformation means cutting hierarchical levels building smaller teams, more agile and more efficient. 

Processes need also to be revised to be adapted to the new size, internal invoicing for example does not need the same effort for a smaller setup!

 The most challenging part is not to cut cost at the same efficiency but is to improve efficiency while cutting costs. This means for IT identifying and retaining the best profiles that are making a true difference and setting up with those profiles small and agile teams. One can understand how different this approach is from the past, where quantity was more in focus than quality.

IT and unmanaged processes

Quite commonly organizations have some undefined or unmanaged processes. This is giving the impression to C level that only IT enforced processes are working fine.

Then, to feel more comfortable, top or senior management triggers projects to automate those unclear processes.

Very often this IT enforcement is not mandatory : having a proper process definition and performing the proper checks would often be sufficient and by far cheaper!

IT is not the only way to setup a process

A little anecdote on this topic : a company was struggling in setting up a sensitive process dealing with revenue recognition between production and sales. As it was not working, it was decided to get it automated (!). IT has been called and implemented a process at unitary deal level creating an IT an administrative monster. Production and sales were fighting on each transaction blocking the whole process.

Stepping back for a while, it was clear that this was the wrong decision and a more manual approach was taken : a weekly report was produced and both parties were invited to discuss and sign it off. The sign-off was recorded in a basic document workflow making the agreement official.

This simplistic approach paid off : due to netting effect, production and sales were much more in sync, talking to each other every week instead of fighting through systems, also creating a smoother relationship.

 IT is not meant to be a change agent

Another impact of trying to automate unclear processes is that IT is being put in a difficult role: IT is becoming the change agent. Instead of managing the required change in the process from the business side, this change is becoming all of a sudden a change forced by IT. Business managers can escape from their responsabilities in managing the change letting IT doing it. This is not so comfortable for IT teams that have to manage the process clarification, its implementation and the change management.

Also, the small example above is telling that brutal force is not helpful. Enforcing systematically processes implementation through systems is not always bringing value although it is sometimes mandatory (managing transaction status, product lifecycle, purchase orders, …).

A lightweight approach can also be considered espacially when processes are unclear. IT is then not any more in the driving seat which gives back to business the change responsibility.

Incident management

It is quite obvious that Enterprise IT systems are complex and that reliability is a day to day fight. To overcome those difficulties, best practices such as ITIL have been deployed introducing state of art processes.

Best practices are not only recipes

Looking more specifically at incident management, which is key for complex systems, a lot of those best practices have been introduced which is a very important move. Nevertheless, what can be observed is that putting in place such processes is sometimes done as following a recipe. There is not always a deep understanding of the reasons why the process as been defined in such a way. Best practices are for sure useful as they provide a short cut but they should not prevent us to think about the essence of what we are doing.

IT Operation should not only defend itself

By definition, for IT operation, the best possible result is to be invisible: if everything works perfectly, then users are not facing outages and are not realizing the huge effort produced on the IT Operation side to achieve this result. Therefore, each outage is only bringing negative impact on IT operation. In this context, incident management and KPIs are seen as a defensive tool to prove that the system is working better that one could imagine. Tools and recipes coming from ITIL are applied giving some kind of label to this defensive strategy.

Understanding the root cause is key

Instead of sweeping durst under the carpet and presenting a defensive approach, there is another possible way: implement those processes and tools in a proactive mode as a means to better understand what is going on. What is important is not the KPI by it self but the comment which goes with it. What is important is not the incident, but to ensure that this incident is not occurring again because root cause has been neglected.

Real improvements are coming when deep analysis is made on the root cause of an incident. This is not easy, sometimes even impossible. It is taking time, potentially slowing down other processes but it is paying off. Of course, IT operation teams in order to look good will try to restart the system asap paying less attention to what caused the issue. This natural inclination should be discouraged by management, forcing an analysis to be performed and an action plan to be defined and executed.

Incident and KPIs reports are communication means

This kind of true transparency from IT operation is demonstrating to users that the IT team is taking care and responsibility. Setting up commented incident reports and monthly KPIs is also giving visibility to IT operation which is not any more the invisible department one can easily outsource. Producing commented KPIs mixing technical and business matters is demonstrating that IT operation is clearly servicing the business bringing its contribution to business development.