The leading web resource for financial technology
   
bobsguide.com

Best practice guidelines for large IT implementation or integration projects

30 January 2012

email this aricle - Best practice guidelines for large IT implementation or integration projects  - 30 January 2012 print this article - Best practice guidelines for large IT implementation or integration projects  - 30 January 2012
Best practice guidelines for large IT implementation or integration projects
Wil Cunningham - Head of WilPower IT Consulting & an ex-RBS IT manager

By Wil Cunningham, head of WilPower IT Consulting. An ex-RBS senior IT manager and now a contractor with Lloyds Banking Group and other banks

Wil Cunningham, an independent technology consultant who oversaw RBS’s Edinburgh Data Centre Optimisation program and has spent the last two years as a senior contractor working on the integration of LloydsTSB and Halifax Bank of Scotland (HBOS LIVE), here shares his best practice guidelines for the key implementation stage of large IT projects. Wil is presently coming to the end of another LBG contract focusing particularly on their disaster recovery strategy, policy and integrated infrastructure, supporting the bank’s business continuity systems.

At the turn of this year, I finished my contracted work with Lloyds Banking Group and I’d like to share a few observations. I was the IT lead for HBOS’ live IT planning function, overseeing migrations, as well as overseeing the UK bank’s Command, Control and Execution functions as Halifax Bank of Scotland was integrated into the organisation after its rescue in 2008. Working as the delivery lead for LBG’s new disaster recovery strategy, I believe I have learnt some lessons that can be used to assist others about the best ways to plan and execute technology implementations.

It’s a sad fact that no one remembers how well a programme solution was designed, tested or built if it fails to implement cleanly. Worse, the programme is remembered for the wrong reasons; the impact it caused, outages suffered, customers affected, the extra money spent / wasted on fixing problems, backing out and or re-implementation. For many installations this final implementation hurdle is normally the least planned as the project is squeezed throughout the lifecycle as the end date nears.

I'd like to share some of my many experiences at major High Street Banks, including LBG and RBS’ EDCO project. I have run successful IT projects involving training, migrations and upgrades, but the implementation phrase is always challenging. An implementation centre of excellence is always helpful. I’d also suggest the following:

Step 1: The Approach – Agree how to implement and the supporting planning methodology
The target end design exists, the testing pre-requisites are happening, the target infrastructure is building, the live date is immovable and for major integrations this falls six to 12 months before go live. Agree how many ‘ proving events’ suit the implementation complexity and split them between technology owned proving events and combined technology / business rehearsals progressing to and beyond the go live. By creating a visionary picture, everyone understands the approach and the incremental stages. Planning is essential.

Additionally, ‘slice’ the end design to demonstrate how it will be incrementally implemented for code drops, cleansed data processes and or target infrastructure scaling. Each ‘slice’ becomes the individual event scope, and through the detailed planning and walk-through process the detailed logical stages of the picture are fleshed-out with the ‘how’. A mandatory two level planning approach emerges, with detailed ‘next‘ event execution planning, along with high-level ‘future’ events pre-requisites status tracking. Expect adjusted scope, hopefully with earlier events gaining more scope from delivered pre-requisites.

Create generic event delivery plan milestones establishing the standard critical path, driving the ‘next’ event design delivery as the input to the execution walk-through, that create execution plans. ‘Ghost’ out live weekend activities, not as scope for particular events, to create understanding of how a ‘slice’ forms part of the whole. If one module works, check to make sure the next one does too.

Step 2: Artefacts – standardising execution plans, tools and engagement rules
Integration projects pull together many IT and business areas, so mandate the execution templates, enabling plan merging to form the complete execution with aligned dependencies. Individual areas develop their plans, but centrally mandate an augmentation sequence with cross-review and challenge that finalises the execution plans. During construction establish who does the ‘do’ tasks and who tells them to execute, as well as who is told after completion. Establishing naming conventions for units, activity types and criticality is paramount, especially when moving backup servers as I have been at LBG.

Tools are largely organisation dependent and most technicians understand Excel. Some managed service providers or internal IT teams produce an activity template with a presentation layer that provides instant impact and re-planning forecasts. Introducing translation and refresh automation will accelerate the planning process, including updating the weekend picture interactively (as most moves happen over weekends), demonstrating real-time progress.

Step 3: The Command and Control structure and communication
Establishing the C & C structure is implementation size and complexity dependent. A repeatable rollout potentially needs a Silver level technology centre controlling Bronze level technicians, with similar business interfaces. Disaster recovery plans could be just two technology levels. Integration plans have IT and business aspects, Bronze to Gold with separate control rooms, conference numbers, controlling several organisation layers, all executing simultaneously, however, with activity ratios of 100 Bronze to 1 Silver and 10 Silvers to 1 Gold, thereby forming a hierarchical critical path.
Mandatory artefacts that should be supplied to all are C & C handbooks including the weekend picture, the support organisation, location, rotas and numbers.

The communication should be part of a wider before, during, and after event strategy confirming the exact details concerning the what, why, how and when, plus everyone’s designated roles. Ultimately implementations are as good as the effort expended in planning, education and communication to the people involved. For multi-event weekends you have to learn, improve and buy yourself contingency time.

Step 4: If things go wrong
Failure planning is crucial. Mandate back-out activities, but create organisations that can resolve problems quickly. Improve the existing incident / recovery capability for Service Level Agreements and ‘problem capacity’ – i.e. create an ‘incident factory’. Integrations might be running 20 parallel incidents, so you need to drastically change your bill of materials to keep pace.

Step 5: Implementation Centre of Excellence
Scaling the above for all implementations provides the basis for a COE that eliminates problems by mandating scope, templates, artefacts and lifecycle planning timescales. Creating an accountable team that understand the target operating model and can become ‘path-finders’ into the installation, will also help to ensure any organisation can implement successfully.

If you do not follow the above guidelines then you could fail at the final hurdle just as implementation is due to get underway, which is more costly than planning to get it right in the first place.

Comments (0)

No one has commented on this yet. Be the first!
Add your comment - Max 1000 characters used
More blogs