I recently had coffee with a friend of mine who happens to be a fellow testing professional and who is – amongst other things – an examiner for ISTQB. It must have been ‘one of those days’ for both us, because we independently commented to the effect that after 20+ years working as a professional tester, it is disappointing to find that the majority of companies we consult in are still making the same mistakes and suffering the same inefficiencies as 20 years ago.

In fact, rather eerily we both commented that during our respective times as professional testers, despite the whole raft of initiatives designed to improve the quality of the IT delivered to customers (e.g. initiatives mainly focused on improving process such as SSADM; DSDM, CMMi; TMMi; TPI; etc. and initiatives focused on improving a testers skill set such as ISEB; ISTQB; etc.), we were still addressing the same sort of problems as when we first started out.

Notwithstanding the fact that we both know of companies that have implemented the processes and procedures advocated by these initiatives and have as a result experienced in significant improvements, the fundamental question is ‘why – after all the initiatives – do the vast majority of IT systems that are implemented fail to deliver the anticipated benefits?’

Many – in all probability the vast majority – of discussion papers, analyses and textbooks will point to the lack of proper process as the culprit. Whilst there is some truth in the assertion that poor processes are a contributory factor, I consider that focusing on process is treating the symptoms but not the fundamental root causes.

What are these ‘fundamental root causes’ of IT projects failure to deliver the benefits anticipated in the individual Business Cases? Based upon my experience working and consulting in a variety of industries and organisations over almost a quarter of a century, the following (in no order of preference) are the main causes of poor quality IT systems delivery:

  1.  Lack of appreciation of the importance of IT to the business

Hard as it is to believe, despite the recognition that IT systems are the lifeblood of an organisation; it is still rare to find an organisation that perceives its IT system to be valuable assets, and manages them accordingly. For example, whilst marketing campaigns are minutely planned, tested on focus groups and refined so that they are honed to hit the right target audience, the majority of IT projects (which invariably support the business’ operations) are rushed into production without consideration of the complexity and difficulties involved.

  1.  Lack of business understanding on IT delivery timescales

There appears to be an ever-growing chasm between the Business’ requirement for ‘pace to market’ and the ability of IT to deliver, especially in respect of major programmes e.g. implementing enterprise systems; achieving integrations or de-mergers.

  1.  Unquestioning belief in the sales hype

Despite all the years of evidence and the ever increasing catalogue of disasters (I feel sure you can make your own list of favourites), it never fails to amaze me how Executives and local and national governmental bodies always buy into the dream that the next super-big IT project will be delivered within budget and on time.

This belief appears to stem from the sales hype from consultancy firms and system vendors that assure the client that yes; it can be done in an unrealistic timescale with minimum customisation, testing etc. Perhaps if ever time a client engages with a system vendor or consultancy for such IT programmes and projects, it should be on a results based contact, with penalties for delays and/or failure. This, of course, begs the question why after all the years of failures, this hasn’t happened yet?

  1.  Lack of effective corporate governance

I am not sure if the fault lies with the executives or with the persons reporting up to them, but in every organisation I have consulted in, status reports were massaged to ensure that bad news was smoothed over – until the inevitable happened.

A recent example of this is a major pharmaceutical and healthcare organisation had 108 projects concurrently in flight. The monthly Board pack showed 8 projects had a ‘RED’ status, 2 were ‘Amber’ status and the others were ‘Green’. My astute readers will have pulled puzzled face since the distribution appears a bit better than anticipated.

The answers is that the ‘Red’ and ‘Amber’ status projects were the top 10 projects that the Board took an interest in, and hence , were (probably) accurately reported and the other 98 projects the IT executive just copied the status from the PMs weekly reports. Surely one of the Board members would have the initiative to ask “if virtually all the IT projects are ‘Green’ are there rising IT costs, delays and failures in the live environment?” I should point out that the same is true, but magnified many fold in local and central government organisations.

  1.  Nobody takes responsibility

The question that always springs to mind – as with the regular banking crises that inflict pain and suffering on millions – when an IT project / programme fails is who is taking responsibility for the mess? There are usually more than enough persons wanting to sit on Steering Committees, Programme Boards, call them what you will, ready to claim the glory in the unlikely event that – despite poor requirements, unrealistic timescales, budget constraints, procrastination by the business over the scope, etc. etc. – the project/programme succeeds.

But when the inevitable happens and the project/programme is delayed, de-scoped etc., nobody is there to put their hand up and take responsibility. In fact, in my experience, there is usually an unwillingness to hold ‘drains up’ type reviews and to learn from the errors. It is the prevalence of this ‘blame free’ culture that stifles lessons learned initiatives, open debate and remedial actions to ensure failures do not keep recurring that is the crux of the matter

My conclusion from all this is that most organisations are managed in a chaotic manner with no effective governance. It has been my unfortunate experience that, even in cases where projects were critical to the success of the organisation, there was a lack of cohesion and will throughout the organisation to succeed. In this context, irrespective of the advice and guidance with regards to process improvement, and the endeavours to bring more rigorous, engineering based disciplines to IT project delivery, the fact remains there should be no surprises that most projects fail.