Mankind has demonstrated the ability to manage large complex projects for thousands of years. Construction projects such as the pyramids of Egypt or the Great Wall of China, among thousands of others, have left a striking legacy.
The ability to pursue challenging goals involving planning and organization is clearly innate in man. It might seem strange therefore that not all projects succeed, particularly IT projects, where disappointment and failure are endemic.
If there is a set of rules for ensuring success, nobody has yet identified them. But there are some patterns of behavior which maximize the likelihood of failure. This article considers some of those patterns of behavior.
Decide what to do, before establishing why you’re doing it
‘We must get our Website operational by July’
‘Why?’
‘Because we’ve heard that’s when XYZ are launching theirs’
This is the classic me-too approach to management that saw, for example, the entire UK life assurance industry rush like lemmings into unit trusts in the 1980s. The early birds benefited from the benign combination of a bull market and retail investors with cash. As always, a market reversal put the small investor to flight and the rest ended up chasing rainbows at considerable expense.
Without any genuine objective, the activity becomes the goal. The only measure of success is whether that activity took place, since nobody established in the first place what was intended to be achieved.
Indulge your own wishful thinking
Of all the causes of failure in human affairs, this is the most consistent long-term performer. It permeates almost all failing projects, whatever other causes there may be.
As a trivial example, I was once assigned to run a project whereby my company was supplying third-party software to an end-user. We were an outfit in the same business as the end user, and the product was their homegrown system, then under development. Within six months it was demonstrable but the multi-phase project was receding at an accelerating rate.
The instigator of the deal sat on the information for several more months. While he was trying to work out how to blame someone else for the debacle, the damage grew rapidly. His company had created a bad deal, which it then turned into a disaster for its client and itself. The folly was in attempting to enter a new market without any investment and with no proper assessment of the risk to all involved. All the parties professed themselves deeply committed to the project.
Assume communication takes care of itself
In the early 1990s a service supplier to the European retail and wholesale banking industry devised a new product based on packaging its services. A new IT system was needed to support it. The key users in sales and marketing were too busy to help in the specification of this system, so it was left to the administration staff to define requirements. The system duly arrived and met all the identified needs.
Two weeks after the system went live the sales and marketing division announced the radical new pricing and packaging structure for the services, which they had spent the last six months devising! The new IT system did not cater for this, as the administration staff knew nothing of this new approach. The system was redundant and discredited two weeks after it went live – and was never used again. The key players had not been involved with specifying a system because they were far too busy changing something fundamental in their business.
Insist on staying with the tried and trusted
It is normal in procurement to insist that the supplier should have done a similar job before. This makes eminent sense, provided the similarity extends to the context. The rapid pace of change in some environments makes that proviso particularly important. Success brings with it the danger of clinging too long to the same tools and methods.
The IT industry is notoriously fast-moving. Yet the working life of a successful business system or software product is many years, even decades. When the time comes for its replacement, the same approach to its development is very unlikely to work as well.
Let technical experts decide
The High Priest syndrome has been a menace in the IT industry since its inception. It represents a cop-out by top management decision makers, some of whom consider IT to be a grubby and undignified pursuit. All too often the technocrats encourage it, only to find themselves used as scapegoats when IT projects which are not business-led fail later down the line.
It is essential that major IT decisions are understood by the senior management team to ensure projects fit into overall business strategy and receive the support they need. The decision making process should be supported by functional management able to provide both advice and its implementation.
Tentative conclusions
The aim of this article has been to identify and classify some typical patterns leading towards failure. The examples are chosen to illustrate the pattern, not to point fingers with 20:20 hindsight at others’ efforts.
The common theme is that regardless of industry or time, failure stems more frequently from psychological causes than from technical ones, the fundamental cause being lack of realism. We have looked at the nature of some of the barriers to clear and realistic thinking. None of us has the ability to be completely honest with ourselves when there are a host of conflicting pressures and desires, but if we aim to make the most of our potential that must be the aim. If the patterns noted above help us to recognize when our realism is under threat, they will have achieved something valuable.
