I spent several years in a team that advised a large international manufacturing company on their software-purchasing strategy. It always amazed me how far the software companies misunderstood our core requirements, but never really took the time to find out what they really were. All their information about us was gleaned from their own non-technical sales force whose scientific knowledge stopped short of ruling out the existence of fairies. And even these guys talked only to our senior management who understood nothing of the details of what went on in their empires, but were happy to bluff their way through in return for a hearty lobster lunch. The technically minded subclass who actually understood the business processes and the technical details of product development were treated with general contempt. They were usually kept concealed from visitors due, it is said, to their bad-tempered candour and their propensity for blurting out embarrassing details of management mistakes.

One Hardware and software supplier, in particular, based their continued prosperity on supplying the company. We were visiting their development Labs one day when they excitedly guided us into a large room where a number of developers were working on a wonderful and exciting top-secret project. They’d been at it for two years. Basically, it was a system for modelling complex castings on the computer, and putting all sorts of stresses on them to see how the structure would flex; based on finite element analysis. For two hours, expert after expert presented aspects of the application. It would, they told us, save huge sums of money in building prototypes, and test equipment. It would revolutionise our manufacturing processes. At the end, there was an expectant hush, and all eyes were on us to respond. I said that any company who purchased the system would have a handy tool, but that it would be no use to us. There was an amazed silence. I asked, in some alarm, who on earth had they had in mind as customers for the product?. ‘Why you, of course’, they replied pathetically. We then had to explain that we already had a CAE system that was far more sophisticated than the one that they’d shown which was able to take development of components from concept through to development, prototyping, test, costing, release and manufacture, all from the same basic wire-frame data model. It was designed to allow multidisciplinary teams in different organisations and countries to work together on complex design processes. Their application could never be made to fit into the way we did business.

There were emotional scenes. They’d spent two years, and enormous expense (investment they called it, somewhat optimistically), doing this work with only us as customers. They had created purpose-built graphical workstations. They had relied only on the occasional remark by senior management of our company, but had never thought to penetrate through to the people who were actually doing the work. We left rather hurriedly, and they were immediately on the phone to those managers in our company who had lulled them into proceeding with the project. Their initial ploy in maintaining that we were mere running dogs, incapable of understanding corporate strategy, didn’t wash. In the end, everyone had to admit that this was another project that would bite the dust.

This story is re-enacted over and over again, with different details, in government and industry throughout the world. Almost without exception, the same mistake is made every time. It is not entirely the case that development team doesn’t do their research first, although cutting code is much more fun than understanding in detail what the application needs to achieve. More commonly, they do not have the experience to identify where the real knowledge about business requirements and processes lies. They never penetrate the fog of misperception that exists in every large company.At an intellectual level, it is obvious that IT initiatives have to be fit for purpose, but emotionally, there is always the siren voice saying ‘This time it will be different, we can evolve prototypes and elicit the full requirements along the way; we can re-engineer business processes, rather than to fit with the existing ones.’ It never is different. Sadly, history just goes on repeating itself.