“By three methods we may learn wisdom: First, by reflection, which is noblest; second, by imitation, which is easiest; and third by experience, which is the bitterest.”
How can you prevent customer migration? When do you have to launch what offer in what pricing model to convince the customer? What products have the potential to be profitably positioned in the market? Decision-makers and other users are increasingly becoming aware of the value of information. The underlying data becomes a raw material that needs to be generated and processed, creating additional value for companies. This is even more valid, the larger competitors’ data skills become or appear to become. Fintech companies, for instance, could disruptively change parts of your business model. On top of that, it is important to consider regulatory requirements which increasingly demand high quality, secure data and processing options for filtering relevant information. This serves to improve corporate management in particular, but in this case always combined with the threat of capital add-ons or other painful sanctions.
Because one or more of these reasons, business intelligence (BI) projects are therefore initiated by all banks in order to meet the requirements for mastering data. In this context, banks encounter a variety of challenges that make these usually rather large projects even more complex than in other industries. While, compared to BI projects in other industries, data volume does not play an exceptional role, especially velocity and variety requirements are highly important for the functions of a bank-specific BI system.
Figure 1 shows a few examples of why banks need to be considered separately when it comes to executing BI projects. With a reliable target vision, the challenges would be easy to overcome in iterations—however, every BI project is faced with an exogenous factor here: regulatory changes with a massive impact on the provision, preparation and analysis of data. Regulations cause uncertainties in two respects. Either competitive situations are created on an architectural, organizational or processual level due to projects running in parallel or the objective, scope and lineup of the current project are changed substantially and can necessitate a complete restructuring of the project. Even if BI projects can be launched from scratch, there will at least be competition for the best employees due to the huge demand for change caused by the “regulatory tsunami”. This is made even worse by the increasing frequency of comprehensive regulatory initiatives (IFRS 9, BCBS #239, etc.), which often leads to a competitive situation, perceived across all levels, between activities that boost turnover or at least preserve the market and regulatory matters.
Against the background of limited financial, human and technical resources, it becomes a challenge to set up an adequate, feasible solution within a limited time frame. The fact that this challenge is not insignificant is illustrated by the large number of BI projects that are either aborted due to lack of success, only fulfill substantially lowered requirements or exceed the budget by a considerable amount.
Some people might ask if, considering these points, it is at all possible to complete such projects within the given time, quality and budget constraints. The good news is: yes, it is possible, which is evidenced by lots of examples—still, that does not mean that it is easy to achieve. The following success factors are fairly easy to identify and understand with just a little common sense:
- Use of target images
- Structured project approach
- Early stakeholder management
- Establishment of (data) governance
zeb experience from a large number of BI projects shows, however, that two additional success factors also need to be taken into account:
- Engagement in “stakeholder management”
- Definition of guidelines
It is, however, not so easy to come up with the bank and project specific detailing of these success factors. This, however, is what decides the success or failure of BI projects. Frequently, these success factors are recognized, but subordinated to seemingly more important or more urgent goals or put aside due to a lack of understanding, simple solutions and apparent escape routes and misjudgments. The connection between the wrong interpretation of success factors and the failure of a project or its inefficient implementation—reductions in quality, cost increases, longer durations—is only recognized or tracked in very few cases.
Therefore, this introduction marks the start of a series of articles in which we present individual success factors based on our project experience in loose sequence. We explain what is behind the success factors, what examples there are for “How not to do it” and what corresponding solutions are preferred by zeb. Often, serious errors with regard to only one of the six abovementioned success factors are enough to turn the project into a failure.