People or Technology? The Real Barriers to Integration

As chief of a software and services company that specialises in channel banking payments integration, I increasingly face the same question from transaction banking customers as well as corporate treasurers: “Why does it take our IT department so long to on-board new corporate clients?”

While the question is music to my ears when it results in the process being outsourced to our group, in reality there are many more client on-boarding components and resulting potential points of failure than the activities of the bank’s own IT department. Among them are:

  • Contractual terms and conditions.
  • Regulatory/market standards considerations such as the single euro payments area (SEPA).
  • Integration with the corporate client’s enterprise resource planning (ERP) systems.
  • Secure connectivity.
  • Transformation of incoming and outgoing message formats.
  • Specialist workflow and reporting.

All of these play a part and require input from a diverse range of both internal and external contributors to the bank. Simply outsourcing to a third party without thoroughly overhauling the on-boarding process merely shifts the problem elsewhere.

As a technology vendor reliant on delivering efficiency to justify its existence, this question is, however, becoming increasingly important for B2 to understand. To this end the group decided last year to examine in depth the issues causing on-boarding delays and, in some cases, outright project failure or an inability to successfully bid for a request for proposal (RFP). The review commenced with a conviction that the solution lay in reducing technology complexity. While this assumption proved to be partially correct, examining the statistics revealed it, surprisingly, to be only part of the story.

Do IT Projects Generally Fail?

In short, the answer is ‘yes’.  B2’s approach was first to look at hard statistics for IT projects and, as specific data for client on-boarding was hard to obtain, then review market research on IT projects in general as an indicator. There were numerous sources available, and while the results felt like something of a platitude, the numbers are worth looking at as most told the same story – IT projects don’t deliver.

For example, the 2011 edition of the Standish Group’s annual ‘CHAOS Report’ found that 37% of all on-boarding projects succeeded in being delivered on time, within budget and with all required features and functions, while 42% were challenged in that they were delivered late, exceeded budget, and/or were delivered with less than the requested features and functions. The remaining 21% were complete failures, being either cancelled prior to delivery or were never used post-completion. Other reports point to even greater lack of delivery; for example one from Dynamic Markets found in responses to its survey the following percentages:

  • Projects that overrun: 62%.
  • Projects that exceed budget: 49%.
  • Projects encountering higher than expected maintenance costs: 47%.
  • Organisations experiencing projects that do not fit requirements; 28%
  • Organisations which have seen business users reluctant to adopt new systems: 25%.
  • Organisations reporting a negative effect from projects on existing systems: 16%
  • Organisations which say that projects failed to deliver expected return on investment (ROI): 13%

Why do Projects so Often Fail?

Assuming that failure is down to the technology is incorrect. Today’s more complex IT solutions, where components from many sources must be integrated to achieve a single, coherent architecture, clearly brings challenges – compared with times past when a company like IBM could provide a one-stop-shop for an enterprise. For treasurers, the widening physical and financial supply chain and globalisation have brought more complexity.

However, component compatibility increases exponentially every year, and information sharing through media such as the Open Source community means that technical components from diverse sources generally integrate and work well together. Ironically, the clearest recent study on project success was from IBM, which investigated reasons for IT project failure and identified five key areas that influence whether a project is deemed a success or a failure:

  1. Project Management (54%).
  2. Business (21%).
  3. People (14%).
  4. Method (8%).
  5. Technical (3%).

Can the blame for failure attach to the project manager? No, as the qualities of a good project manager, the availability of excellent methodologies and advice on best practice, and the value of really skilled practitioners are well known and need no repeating. So while good project management is essential to success it is no mystery and, if B2’s experience with client banks and corporate is a guide, it is safe to assume as a given with many channel banking projects. So if not technology or management, then what is the root cause?

Communication and Resource Planning: The Real Culprits

A technology vendor will likely cite weak technology as the chief cause of failure, while a management consultancy will blame bad project management or lack of business subject matter expertise. However, B2’s review of market research showed overwhelmingly that poor communication is regarded as the main culprit (in a Computer Technology Association review 28% of respondents placed it top). The second major cause was insufficient resource planning and the third – umbilically linked to the second – was unrealistic deadlines.

At this point in the B2 Group study, our view was that reducing project complexity through smart use of technology and methodology would reduce the number of communication lines and resources required and hence reduce the risk of failure (in the case of client on-boarding generally delay and/or cost overrun). Market research supported this view, with both IBM and the British Computer Society studies confirming that project communication and resulting success is a function of simplicity.

Reducing the Cost and Lead Time

Armed with its findings, the group needed to apply them to the real world of bringing efficiency to cash and treasury managers at banks and corporates. To this end two questions were posed in relation to channel banking integration:

  • How can corporates and banks reduce the complexity of technical components?
  • How can they reduce their reliance on scarce expert resources?

To find answers, B2 reviewed its own client projects and noted three key relevant elements: integration, connectivity and testing.

Integration involves both the corporate systems (typically ERP or accounting systems) and the core banking platforms, plus potentially clearing systems as well. Message standards such as the International Organisation for Standardisation’s (ISO) or proprietary formats for popular ERP systems like SAP abound, but B2’s experience is that sticking to one standard like ISO is a challenge, especially in today’s market where corporate expect banks to adapt to their way of working, not the other way around.

The conclusion from reviewing the most successful B2 client projects was that combining best practice use of middleware technology and subject matter expertise is essential to success and that best practice meant a simple mechanism to take any file format in and convert it to the necessary internal format via a single ‘canonical’ intermediate format. Canonical in this context refers to multiple message formats of a specific transaction type – such as a payment – from different sources being automatically converted to a single format and then converted again to multiple outgoing formats. The opposite is ‘direct’ mapping, where each incoming format is directly mapped to its corresponding output format. Direct mapping is marginally faster at run time, but slower to develop (two programmers at a time can work on a canonical transformation) and much harder to maintain.   

Subject matter expertise was essential in defining a flexible enough canonical format in the first place and also adapting various external client and market formats as business needs arose. Those projects involving single ‘direct’ mappings (i.e. a one-off build for each client on-boarded) were slower and required more resources, so the former approach, while requiring more up front planning, resulted in long-term benefits with reduced complexity.

Connectivity examples clearly showed that use of remotely configurable technology brought key advantages in lead time and modern advances – even in the last few years – mean that security, performance and low-cost are no longer mutually exclusive. Those projects where the bank’s staff had to visit the client site to install connectivity solutions, and where the connectivity required complex changes to the client infrastructure – for example the firewall – tended to overrun.

Testing was found to be a key area for delays, largely due to bank’s being unable to offer all clients their full testing service. Precious expert testing and on-boarding resources could only be made available to the biggest clients, so small to medium-sized enterprises (SMEs) needed to adapt precisely to the bank’s requirements as no bespoke service was available due to these resource constraints.

This also affected the bank’s ability to on-board clients in parallel. None of the bank’s B2 services is able to hire unlimited on-boarding personnel due to availability and cost, and our research showed that those banks able to offer a self-service testing environment, where the client could generate appropriate documentation and simulate testing autonomously were able to bring clients on board faster, cheaper and in greater numbers.

Good News for Corporate Treasurers

Delays and cost overrun during the client on-boarding process is rife, but not simply because of IT departments or project managers. Technology and best practice exists to simplify the process and hence aid communication and reliance on scarce expert resource, so the adoption rate by corporates and banks is increasing, albeit slowly. Standards such as ISO do bring long-term benefits in simplifying the on-boarding process but front-load complexity, as do initiatives such as SEPA.  

While smart use of technical components, such as self-service test platforms, automated documentation, low-cost secure connectivity, and efficient message transformation all help enormously, there will always be a place for the best channel banking subject matter experts and skilled project managers. To quote possibly our most venerable source of market research, Albert Einstein: “Things should be made as simple as possible, but not any simpler.”

15 views

Related reading