By Maeña Twomey, integration programme manager, Lloyds Banking Group
Maeña Twomey, programme manager for the Halifax Bank of Scotland (HBOS) Live project, which integrated the bank’s operations and its disaster recovery capabilities into Lloyds Banking Group’s over-arching IT infrastructure, looks at the issue of how to enhance assurance on large cross-divisional change programmes. The business case and managerial control of the integration of the two large UK banks was aided by live trailling as a way to prove large changes in a safe platform, which cannot be fully replicated in a test environment.
The growing trend for larger ever more complex change programmes calls for an elegant approach to test subsequent target operating model impacts. Live trialling, or piloting, is a way to do this by enhancing standard testing to prove the operating model works post-implementation in a low risk manner.
Traditional testing assurance practices
It is widely acknowledged in change programmes that IT, procedural or managerial issues are exponentially more expensive to address the later in the lifecycle they are found. None are more costly than those problems found after implementation, so identifying problems early pays off.
While this principle commonly refers to system defects the same principle applies to operating model issues too. These issues cover service level agreements (SLAs), team-to-team interfaces, the organisational flow of data and services and, critically, the customer experience. By carrying out live trials you can address these issues more thoroughly than you can using traditional assurance procedures, with staggered ‘go lives’ assisting the trouble-shooting stage and customer feedback actively sought before a full roll out.
Traditionally, financial and other organisations will replicate production situations as far as possible by creating a pre-production or test environment. This aims to prove the technology and usability. However, a production environment has uniquely ‘evolved’ and therefore only in rare and costly circumstances can you fully replicate it, especially if external customers are involved or large complex organisations that are trying to merge. In addition, what is generally overlooked is the requirement to prove any new processes end-to-end and therefore the target operating model is deficient.
Traditional testing assurance methodologies include the need to:
- Gather requirements
- Design and agree the solution
- Build the technology
- Test the solution
- Train and communicate it to the users
- Roll out.
While widely used, this model has shortcomings when it comes to large, cross- divisional change programmes where there are a significant amount of inter-departmental dependencies. This was certainly true of the huge HBOS / Lloyds integration.
The key shortcomings of a traditional approach are:
- Limited proving of inter-divisional hand offs
- Limited proving of SLAs (both internally and externally with third party suppliers)
- Limited proving user and customer experiences
- Limited proving of all of the above in a production environment: Certain aspects of a production environment are inherently unique (e.g. reference data and batch processes.
Issues resulting from these limitations are generally customer-facing and therefore have an impact on an organisation’s reputation and in the worst case scenario its regulatory compliance. Take, for example, the retail bank account opening procedure for a new product. Looking at the components involved in this, the workflow is as follows:
- Open an account via telephony, online banking or in branch.
- Account opened within agreed timeline
- Card, cheque book, welcome letter, PIN, etc all issued.
Now look at this same process from an operational perspective:
- Open account is initiated via different systems \ routes and passed to a single back office team.
- This team must then deal with the opening of this account and pass it onto additional teams (e.g. fraud prevention units).
- The account is opened and then internally new letters are printed and issued
- At the same time data is sent to an external third party to produce the card.
- Within this process you have numerous internal and external dependencies. Teams are all dealing with material (the product) and data which must be seamlessly passed, worked upon and understood all the way through the process.
This is a complex array of change procedures all of which are customer-facing. In order to be successful there is one major dependency – namely, all departments and third parties must work seamlessly throughout the lifecycle and understand all the requirements exactly. Good communication will be crucial in achieving this.
It is not easy to map workflows accurately and all too often this does not happen effectively, hence the need for traditional testing assurance. However, this model falls short when proving customer and operational aspects end-to-end. Live trialling meets these needs because it is not so internally-focused.
A better way: Live trailling overview
Standard project lifecycles exist because we will always find issues with the design and build of technology and operating models. The traditional project lifecycle and associated testing assurance is not entirely aligned to addressing issues realised when the technology and operating model are brought together in real production environments where the level of change is significant.
So what can we do to address this? The answer is to build on a simple idea commonly used in small single change projects – the pilot stage. Rather than simply pilot a system in a ring fenced simulated manner look to extend this concept to include a customer and user experience in the real world.
Look not at the minutia of the detail – for example, the screen layout and so forth – but instead at the bigger picture: treat the systems as a black box to be mined for data. Operate in a controlled post-implementation situation and monitor it, both to check the technology works and customer satisfaction.
Implementing live trailling
The key principles of live trialling to remember are:
- Remember, your production environment is inherently unique and simply cannot be exhaustively replicated.
- All traditional testing assurance checks still need to be carried out, such as a system test, user acceptance testing, and so forth but in a more realistic way.
- All traditional implementation proving is complete (e.g. training, education).
- Your live trialling must be outcome focused: you need to identify key outcomes of a process and prove these in a real-world pilot. The key assumption is that all underlying functionality is stable: prove it.
The theory is fine, but the live trialling approach is about doing and it involves:
Step 1 – Maintain the status quo: Deliver your change in line with the traditional testing assurance model. Fully test and implement your change.
Step 2 – Know your 'moments of truth': Identify your critical business processes, inter-divisional hand offs and corresponding SLAs. Use your frontline and business subject matter experts to identify these. Identify the outcomes you wish to prove to gain assurance and the checkpoints in the end-to-end process.
Step 3 – Manage the risk: Create the ability in your production environment to operate the system end-to-end in a ring fenced manner. For example, in a retail bank environment, such as the one we were faced with, create a new sort code against which customer accounts can be created and easily managed; alternatively create a realistic data format which you can easily manage and pilot). Confirm the readiness and support of your third parties in doing this.
Step 4 – Start small and build up: Use the real users and not testers to carry out the proving stage. Carry out your business processes in a business as usual (BAU) manner. Start with small and simple levels of assurance and increase the breadth and complexity of the pilot as your assurance increases.
Step 5 – Monitor the outcomes: Monitor the outcomes in three areas, covering customer and user experiences, plus technology outcomes.
While there is no substitute for traditional testing in carrying out live trialling you will have realised extra assurance for:
- The integrity of your target operating model design.
- Your cross-divisional hand off and SLAs.
- The integrity of your production environment when new data is introduced.
- Your colleagues’ readiness to accept this change.
- The readiness of third parties, such as cards scheme partners for instance, to meet your requirements.
Live trialling is inherently simple, low cost and low risk to implement as you leverage existing implementation activities to deliver this.
Introducing this phase into a change management programme, such as the one we undertook integrating HBOS into Lloyds bank after the takeover, will bridge the gap between traditional change assurance and what is required for large cross-divisional projects. It will benefit you and your users and save you money further down the line, via enhanced performance and less clunky IT architectures and human procedures.
- Please see bobsguide's earlier article addressing the IT and technology management elements of the HBOS Live project here, as opposed to the business elements outlined above.