Mitek CryptoCurrency
Subscribe to our e-newsletter
Follow us on Twitter
Privacy and cookies
Established 1995
Tuesday 23 October 2018

LATEST NEWS

Getting it right

Written by Wil Cunningham
09/11/2011

Wil Cunningham is an independent consultant who was contracted with LBG as the IT Lead for HBOS LIVE IT Planning, Command and Control and Execution for LBG/HBOS Integration, now the Delivery Lead new LBG Disaster Recovery Strategy. Here he discusses the best ways to plan and execute implementations

It’s a sad fact that no one remembers how well a programme solution was designed, tested and/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 hurdle is normally the least planned as the project/programme is squeezed throughout the lifecycle.

I’d like to share some of my many experiences at major High Street banks, where I ran successful implementations and an Implementation Centre of Excellence that solved this problem by focusing on the following...

The approach - Step 1: 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 6 to 12 months before 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 LIVE. By creating a visionary picture, everyone understands the approach and the incremental stages.

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. So the implementation picture/plan of activities of a pre LIVE weekend event (rehearsal for instance) would have the LIVE weekend (ie post-go) elements ghosted/grayed out both in the picture and the plan. In that way, people could understand how the scope of a single event formed part of the whole. We did not execute the grayed out elements.

Step 2: Artefacts - standardising execution plans, tools and engagement rules

Integrations 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, and who is told after completion. Establishing naming conventions for units, activity types and criticality is paramount.

Tools are largely organisation dependent and most technicians understand Excel, some MSP; combined 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, demonstrating ‘real-time’ progress.

Step 3: The command and control (C & C) structure and
communication


Establishing the C & C structure is implementation size and complexity dependent. A repeatable roll-out potentially needs a silver level technology centre controlling bronze technicians with similar business interfaces. Disaster recovery plans could be just two technology levels. Integration plans have IT and business, 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 supplied are C & C Handbooks including the weekend picture, the support organisation, location, rotas and numbers. The communication should be part of a wider pre, during and post-event strategy confirming the exact, what, why, how and when and everyone’s 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 SLAs and ‘problem capacity’, i.e. create an ‘Incident Factory’. Integrations might be running 20 parallel incidents, so you need to drastically change your BOM to keep pace.

Step 5: Implementation Centre of Excellence (COE)

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 TOM become ‘path-finders’ into the installation, ensuring that the organisation implements successfully. Or fail at the final hurdle which is more costly than planning to get it right first time.



Related Articles

Microsoft

Most read stories...
World Markets (15 minute+ time delay)