To hear more about our comment visit our video feature on the Independent website click here

The financial sector is more IT driven than ever before and while there are many aspects to integrating businesses in any sector, in the financial services sector IT integration will be the key success factor in realising the benefits of any integration programme.

The figures speak for themselves: Some 50% of post-merger integration activity in the banking industry will fail due to IT complexity, according to Gartner. 75% of managers surveyed in a Hay Group study in 2007 admitted they didn’t even consider how IT issues affect operations until after the merger. According to a study by Bloor Research in 2007, 79% of M&A activity ignores IT integration.

Although mergers can net exceptional benefits, all too frequently the focus is on ‘completing the deal’ and the original business case, or benefits, can get lost during the delivery of the programme. Here we take a look at why this is and explain what companies can do to ensure they deliver the benefits as stated in the original business case.

Experience and Leadership is Critical

Organisational changes of this magnitude require strong leadership from the outset. Most companies will be experiencing a change of this type for the first time. Although they may have senior people with experience of integration, and this will be important at the business leadership level, very often this experience cannot be deployed on the project and/or only relates to specific areas.

Often these programmes will encompass the entire organisation and will need strong focus and support from all of the top executives. This support will be needed to make the hard decisions up front, such as shutting down all other non-mandatory work, or scoping the project to deliver only the integrated solution. This can mean “the business” needs to be told it cannot have any new development or products for this period. These are just some of the tough choices that may have to be made.

Don’t Underestimate the Challenge

Our experience is drawn from working on the largest programmes undertaken in Europe over the past decade. Here are the key challenges to consider at the outset:

1. In the due diligence stage work should take place to establish the approach to dealing with IT complexity of the merged organisations. Failure to do this can cause knock-on difficulties at later stages when setting overall strategy is much more complex.
2. The increasing size, complexity and time pressures around these programmes make them more and more challenging. Data and application redundancy, complex and incompatible software and hardware platforms are just a few of the challenges. At the same time, many of these organisations have other complexities from previous acquisitions, growth of divisions, subsidiaries or business units.
3. Financial constraints continue to plague even the strongest of organisations. Objectives must be achieved quickly to deliver the financial benefits. IT spending continues to be constrained and many analysts believe this will continue into 2018.

Some Key Decisions

Much of the research into post merger integration has shown the value of starting preparations early and not diving into the detail too soon. A key aspect of this will be the definition of a Programme Office and initiating the planning process to understand how the programme can be delivered.

Some of the key areas to consider are:

• Who will design and lead changes to business operating models to drive operational efficiency?
• How will IT platforms be consolidated to support change and future growth?
• How will common standards and processes be developed and adopted to ensure one way of working across the merged organisation?
• What is the organisation good at already and in which areas does it need specialist help (ie data management, security, testing etc)?
• Who is the leadership team and are they of ‘one mind’ and focus?

Engagement Model

Often companies have never done anything this big, so they rely on bringing in an integration partner to deliver the programme with them. The way these partners are engaged can have a major impact on the benefits realised.

Most companies embarking on an integration wish to retain control of the programme, therefore they engage a partner or several partner organisations on a time and materials basis. This means that the partners’ objectives are not necessarily aligned to the organisation undertaking the integration.

The misalignment of objectives becomes more evident as the programme progresses and as the partner, or partners, start to take more responsibility/roles than were initially envisaged. This predicament can be avoided up front by recognising that partners will be necessary and also by being realistic about the capabilities of your organisation and the likely breadth of support you might need as the programme progresses.

By dealing with your procurement model up front you can also reward partners for working together and delivering the benefits outlined in the business case (or additional benefits). This way the entire programme will mobilise as one team, rather than competing factions. It will also result in beneficial discussion with all teams in efficient ways to deliver the desired outcome, as opposed to suppliers trying to get the maximum income by filling your programme with “bodies”.

During the Programme

There are many things to consider in the execution stages of a programme of this scale. In our opinion, to achieve a successful outcome there are two things that you must ensure:

1. Your top executives are engaged in the programme and committed to delivering the benefits in their area as early as possible. You can aid this by ensuring that the benefits are “baked” into the plans and are being tracked on a regular basis. Ensure your Steering Group meets regularly to deliver this.
2. Your IT target operating model is the simplest it can be, don’t let the boffins use integration as an excuse to put the latest and greatest in. By keeping it simple and focusing solely on integration you can let the business have their systems back in the shortest time possible.

And Finally ….

How should you select the organisations to partner with you? Many consultancies will tell you how they would run a post-merger Integration, however when you engage them they often deploy processes based on theory rather than experience.

We advise in choosing a few specialist suppliers and possibly one or two larger consultancies (dependant on the size of your programme). The specialist suppliers will help to keep your costs down and keep the larger suppliers honest. Also by taking this approach you can ensure that the resources deployed on your programme deliver in a consistent manner, as opposed to the contract market where your management overhead will be significantly more.

Make sure your partners commit to deploying practical solutions with people with real integration experience, rather than complexity or an inflexible approach.

In my opinion businesses, rather than dragging their feet are, all too often, wrestling with ill-defined, ill thought out and very badly communicated regulation.  

In order to succeed the Prudential Regulation Authority (PRA) and Financial Conduct Authority (FCA) will need to be far more prescriptive and much clearer in what is and is not permissible under the new regime if the spectre of financial meltdown is to be confined to history.

The crux of the problem is that recent regulation in the UK has all too often been open to interpretation, too ambiguous and especially poorly communicated. This has made it difficult for a typical Compliance team to clearly articulate to its ‘Business’ what has to be done to achieve Compliance, by whom and by when.

Regulation is all too often drafted with too many ‘shoulds’, ‘coulds’ and ‘mays’ in the specific detail. This means interpretation is left to individual organisations’ Compliance Teams who are regularly seen as ‘harbingers of doom’ and are constantly asking their ‘Businesses’ to give up valuable profits to implement expensive Regulatory Programmes that have no discernible benefit, other than the measures being implemented ‘may’ ensure regulatory scrutiny is averted.

Since its inception the FSA has failed to properly articulate what measures must be undertaken to achieve full Compliance. Perhaps the introduction of a formal ISO type standard might be a way in which Compliance standards can be evidenced and approved but that requires unprecedented decisive and definitive action on behalf of the Regulator.

In the end Businesses will do as they’re told with regard to Compliance but that telling has to replace the ‘shoulds’, ‘coulds’ and ‘mays’ with ‘musts’ and ‘wills’.

Sitting on the fence (and more specifically the glib use of ‘Risk Based Approach’ in practically every communication), did nothing to protect financial institutions, their shareholders, their customers, their employees or the wider population from the events and fallout of the Financial Crisis of 2008 (and beyond).

These lessons must be learned in the new world.

• Vendors tend to modify and customise the handsets so emulator testing does not represent actual behaviour
• Location based testing and network environment cannot be tested in an emulator
• Interoperability with other functions happening in parallel such as a phone call and how it affects the application under test and behaviour cannot be done in an emulator.
• Behaviour of the software on the device under different cellular network is also difficult to test in emulators. Some networks may have restrictions, while others might not. This is particularly true when the device is used in different countries.
• Multilingual software requires testing by changing the locale, which may or may not be possible in emulators.
• Security testing is even more of a concern amongst mobile users. Sensitive data must be protected and each device may have different security holes, which must be tested for. Also Cellular networks are know to be less secure and prone to hacking so extra testing in this area is required to make sure that data is secured appropriately.

Other functional validation such making sure that application is usable with devices of different screen sizes is also extra requirement in mobile application testing. This is because sometimes there is requirement for the software to work on a particular operating system for example Android, which supports tablets of varying screen sizes and different sized mobile phones. Although this is a very high level run through the issues I hope I have highlighted the need for some careful up front test planning and design before embarking on the testing of mobile applications.

As a direct result mobile applications become more and more attractive to companies as a means of 24/7 connectivity and information access especially with technological innovation in superfast 4G networks, NFC (Near Field Communication) devices, and availability of augmented reality and bar codes scanning. Mobiles devices using these technologies are revolutionising ways in which companies are conducting their business and spending in this area is increasing substantially.

Given the appetite for mobile devices from all sectors, there seems to be a rapid growth in different types of such devices coupled with a number of different operating systems to support them. We believe that testing these new applications is going to be a critical factor in making them successful and ensuring that companies do not suffer brand damage from releasing them in an unstable state.

So what are the challenges in testing applications on mobiles devices? First of all they don’t simply imitate Desktop environments but have their own user interfaces, business workflows and infrastructure dependencies. There is a choice of thin and thick clients and they must operate on a 24/7 basis, so businesses need to build new services and infrastructure separate from those servicing their normal applications. All this of course increases the risk of quality and performance problems occurring. Hence not only functional but performance validation of these applications is very important to mitigate the risks. Over the next few weeks I will be covering the various challenges in testing these applications.

The Oxford University research on big IT projects is timely given the increasing financial constraints on UK business. Businesses need to grow but are becoming more and more scared of engaging in large business change projects, fearing the worst outcomes we become less competitive, preferring the status quo, than the career limiting step towards business transformation we so dearly need to compete in the world market.

So, what is the answer? Some of it addressed in the article, over sized and over complex, over ambitious use of new technology are a few of the issues. When technology is changing so rapidly it is no surprise that projects as big and as complex as the NHS National Programme for IT had to be curtailed. It is clear that the big outsourcers and consultancies do not have the answer as they are often in the middle of the mess that ensues from a badly structured project. Despite the fact that the study highlights that the use of new technology introduces more risk. Many other sectors seem to manage this risk competently. In Grand Designs the use of new and exciting building technology rarely causes project failure. As my father used to say ‘a bad workman blames his tools’!

The fact is we need to adopt some of the rigorous control we employ in the more successful sectors such as construction. At Certeco we have adopted a planning method that encompasses the approach taken in constuction projects, this provides more rigorous programme office functions, ensuring governance and change control through the programme. Importantly, and this has started to happen in recent projects, the business users must provide more than sponsorship. They must be actively engaged in the process with a team that translates IT speak into business language so that the project is a Business venture NOT and IT Venture.

The early part of a relationship, during the period in which the transition away from the existing testing resource models to the new one led by the chosen testing supplier takes place, provides a number of risk areas. If not controlled properly, these can manifest into issues long into the ‘business as usual’ work.

During this early period, the real working practices begin to embed, including staff integration and  how much knowledge transfer is expected to “push” or “pull” and staff quality. The more formal or contractual aspects are tested for their validity here , including ramp up time and consistency, onshore /offshore ratio and dependencies expected from the supplier (such as quality documentation).

The risks around how the transition itself is performed need to be controlled. The supplier transition methodology may tend to the generic, not allowing for the state of a project through its lifecycle, or the peculiarities of technology, working practice or specific project issues.  The tension between project and its desire for continuity and organisation and the desire for early transition (and consequent economies) must be managed, so as to maximise benefits and early “buy-in”.

Once the model is in place and in the ‘business as usual’ state, the focus is on achieving the benefits whilst reducing the risks. Key ones to mitigate throughout the engagement are

• Late or cumbersome engagement with projects, leading to delay
• Overly narrow view of testing scope, leading to testing gaps
• Inaccurate estimates (too low leads to gaps or reduction in quality, too high leads to poor value).

If the supplier is offshore there are typically risks around the availability and support for test environments, time differences and cultural differences.

For the benefits of outsourcing to be achieved, it is vital that the service and quality do not suffer. Identifying and managing risks is a pre-requisite to achieving these benefits.

Risk Management – A risk management solution can provide not only documentation but workflow, evaluation, analysis, simulation, visualisation, reporting and remediation. That way the risk owner can identify and create appropriate controls to track and manage risks. Considering cost, quantifying losses and savings is important. Features such as centralised controls, cost-benefit analysis and the linking of regulatory requirements may be valuable in an enterpise solution.

Performance Management – I guess whereas risk management and audit are areas we take for granted, performance management is the holy grail. This is the point where it really is imperative that we architect a solution that integrates information from many silos and provides feedback on how performance of the organisation is affected by the risks indicated. Ideally the GRC framework will unify and link strategic objectives, KPI’s, targets, resources, Key Risk Indicators amongst other critical information to enable the strategic and operational plans to be monitored and adjusted as the business executes.

As you may be picking up, the linking up of information and making it visible across the business is a key theme. In our next review we will identify some other critical factors in designing a GRC solution.

Audit Capabilities
A key aspect of any solution will be how it support audit. Getting the data out quickly and having the flexibility to drill down when certain parties are focusing on a specific area will be critical. Obviously a key factor is identifying risk and then being able to manage it through visibility of the information relating to risk. But this no longer has to be constant review process within a business area and it can be made to be always visible at certain points in the business cycle. When you are building a solution think about lightening the burden that audit has on the business. Plan a solution that can support a collaborative view giving the audit team the information, whilst minimising the impact on a specific business area, allowing them to get on with their day job.

Integrated Management
Avoiding information silos will always be difficult but an ability of integrate/join data to provide a holistic view of the enterprise is essential. We have already discussed audit, highlighting that if risk management and audit can access an integrated view we get a focus on tracking risk in our audit process, if we can integrate policy management with compliance then we can monitor compliance on our policy portfolio. To achieve this the way we extract data from underlying systems will be critical, don’t be misled by ERP integration claims, take a closer look at how data can be combined to provide the most flexible solution.

Stay tuned for some more tips in my next blog where I will be considering compliance functionality and performance management amongst other topics.

Occupational psychology studies suggest that people are actually more social when using computer mediated communication, in certain situations it can often be a more productive environment for generating ideas but, identity theory research has evidenced that people will be discriminative even on a superficial level, which can cause “them and us” challenges for teams working in different locations.

While there is no silver bullet to help overcome these challenges, there are small measures which can help. In the past, I have created a virtual team table, where team members provide a photo (or image they feel represents them if they are uncomfortable sharing photos) to be used when having teleconferences. Managing communication is key, make use of mailing lists and wikis to ensure that information is communicated at the same time, ensuring that no-one feels left out. Ensuring that ownership of tasks is evenly spread across the different teams can help to minimise the feeling that one location has all the knowledge and power, creating harmony across the various locations.