TxB/1: Avoiding Programme Failure. A Ten Times Better (TxB)©️Approach.

So there I was …                                                                                             001

When I was COO at Capita Public my weekly communications to the team were called “So there I was …”. They contained a reflection on something I had observed during the week, and then tried (often in vain) to make some sense or learning from the observation, sometimes even with a hint of humour.

Having started to look for a new job recently, I have found myself with a bit more time to reflect on life – who am I, what do I want, who do I know, what do I stand for, how do I do things, what does good look like, what are my core skills? … and even, am I relevant anymore?

Thinking and preparing for applications and interviews has caused me to re-visit, distil and attempt to synthesise many things I just do naturally and take for granted after (ahem) quite a few years doing them, so that I can explain or describe what I do to somebody who doesn’t even know me.

For instance, one of the topics which is often discussed relates to programme failure and recovery – why do they fail and what can you do to recover them?

So, after some thought here is starter for ten of ten reasons why I believe large scale IT/digital programme implementations fail. It’s not a comprehensive manual, book or progamme management process – there are several excellent publications out there. It’s my list of the top ten practical reasons from my own experience of why programmes fail – and if fixed or attended to successfully, in my view will lead to performance being ten times better.

I would love feedback and comments to help me improve my thinking.

One: Clear and comprehensive requirements gathering, agreement and documentation, and crucially all wrapped up in a requirements traceability matrix which runs from capture, through design, contracting, supplier selection, testing, training, implementation, change and post implementation management

Two: A complete testing regime, incorporating agreed end to end test scripts, how tests will be jointly managed, customer involvement and sign off of testing and results, an agreed definition of entry and exit criteria, an agreed categorisation of testing failure, an open and inclusive tool for monitoring, reporting and prioritising tests and fixes plus the velocity of fixes, and a management method for agreeing what is necessary for go-live and what can be left until later, when the going gets tough – which it will

Three: Data migration. A real bête noire with me this one. A data migration strategy needs to be agreed, then executed that will allow for real or representative abstracted/obfuscated data (where security concerns are key) to be tested, with real world sizing and transactional volumes, and for the actual data plus increments to be able to be migrated to the target operating or test platform in a satisfactory timeframe and manner to allow testing and maximum fidelity of data once operational, with no, or minimal, data left behind or in error

Four: Environments and interoperability, ensuring that all environments and interfaces, whether production, test, staging, disaster recovery or other are exactly similar to each other in terms of hardware, operating systems, patches, applications systems, sizing and configuration, and that these are kept wholly in step when any change cycles are implemented or forced

Five: Security and firewalls, need to be designed, implemented, patched, upgraded, simplified where possible and basically attended to regularly to enable systems to continue to inter-operate without some cataclysmic performance failure, drop out, or worse some form of cyber incident. Hand in hand with this is the absolute necessity to limit access, using appropriate controls, to all systems, particularly production systems, to very very few personnel to avoid human error – which will be likely to happen under stressful and demanding circumstances

Six: Non-functional performance There is often an understandable tendency to concentrate efforts on functional performance, but achieving satisfactory non-functional performance, in the new system, on new hardware, perhaps with new expectations of the benefits of the system is absolutely critical. Time, effort and money needs to be spent up front in ascertaining what is needed for example in the design or coding or in raw “grunt” power to achieve this. I have seen so many times when a programme is not able to be implemented in spite of the obvious functional advantages, because the transactional performance for instance is so much worse than the old system

Seven: Usability and UX experience. This is an absolute killer, and plays to several of the items above. Put simply if you don’t have a great UX or at least one that can be accepted, used and adopted by your users – who in the end are responsible for the smooth running of the business, then you are toast along with the programme. Involve users early, involve them at every stage, listen, adopt and adapt to their recommendations – they know the business intimately

Eight: Change management regime, which can allow for change (hopefully minimised by the satisfactory application of item one above – requirements) and changing circumstances, especially on large scale, long term programmes and an ability to be able to design and implement this change within a flexible and adaptable system, set of applications and environments, whilst maintaining progress on the plan within an agreed commercial framework. Equally important is knowing when to freeze changes, and when to reject them to prevent “nice to have” or unnecessary requirements creep

Nine: Leadership. A compelling, credible and truthful vision and reason for the programme needs to be communicated -  “how and why we are doing this, how will we achieve it and what it will look like when we are successful”. Real leaders need to show not only that they believe, that they are on the journey and feel your pain, but also that they are prepared to take some pain themselves in helping, assisting and responding proactively and reactively to escalation. The practical implementation of this will come down to real hard science of planning, benefits management, governance, controls, risk management and open, wide and regular communications along with leaders being present

Ten: Finally and crucially people. Too often programmes are under-staffed, raided for skill and resource, for another fire in the forest elsewhere in the organisation, or asked to undertake tasks for which they are either unsuited or for which they are untrained. Remarkable resilience is required on programmes and for the leaders of the programme to be genuine, and create a real esprit de corps for the programme team to believe they will succeed come what may