An engineering approach to IT

In my last Industry Insight, I discussed the critical factors that require attention in order to avoid the 70% failure rate of IT investments. This month, I present what I term "an engineering approach" to managing IT; in other words, the attitude to IT investments that is required to successfully apply the seven critical factors.

Many of these factors seem self-evident and some would argue that many are applied rigorously by many in the IT industry. To this I would reply that some are doing most and in some cases all of these things, but at least at some level they are doing them intuitively or as a result of particular knowledge and experience rather than as part of a formal industry-wide approach.

Accordingly, the following approach and attitude is advocated as a framework for the industry as a whole.

I offer what follows against a background of formal training in engineering and an informal training of designing and building things since my early childhood and throughout my adult life.

In practice I have learned that engineers do NOT design bridges to stand up, they design them NOT to fall down. It probably takes between five and fifty times more effort to design a bridge not to fall down than it takes to design a bridge. The same applies to IT solutions.

So what is required for a successful IT solution?

* Meticulous, documented design detail: A detailed specification that a business expert can understand without understanding IT except in the context of a person who sits at a computer and uses the solution.

* Meticulous, documented planning detail and costing: Detailed plans based on detailed understanding of what it REALLY takes to successfully implement a solution that works, including the factors set out in my last Industry Insight.

There is a great need for greater diversity in most IT project teams.

James Robertson, independent management consultant

* Multi-disciplinary teams and specialists: By my estimate it takes between 150 and 250 distinct professional disciplines and trades to design, build and take occupation of a large building or other engineering structure. Yet IT projects are typically undertaken with a fraction of the number of distinct disciplines with professional expertise in the management of change, communication, psychology, etc, being the most notably absent on most projects. There is a great need for greater diversity in most IT project teams.

* High professional standards and legal accountability: Engineers, doctors, lawyers and accountants are required to be certified and licensed in order to practice and these requirements are set out by statute. There is no corresponding requirement for IT practitioners.

If we extrapolate from the abovementioned professions, there will be a day when IT practitioners are sued for non-performing IT projects and probably a day when criminal charges will be pressed for negligence that destroys otherwise successful companies.

The reality of legal accountability is, in my opinion, prerequisite to a more sober and carefully considered approach to IT by both IT practitioners and business executives. An IT "Enron" is not too far away.

* Cross-checking and double-checking of all important details: Engineers do not issue significant drawings and specifications without checking and double-checking, a second signature and co-accountability is frequently a requirement.

* Physical world metaphor and impact analysis: I have found that relating IT approaches and systems to similar decisions and projects in the physical world is frequently a basis for a more sober assessment of what is planned. A large information system is just as complex and costly as a large factory, yet people frequently do and say things about such information systems that they would not contemplate for a physical factory.

* Engineers know the limitations of their expertise and when to call in specialists: "The system cannot do this" is a statement that I regularly encounter. On closer inspection it frequently turns out that this means "I don`t know how to get the system to do this". Frequently, in my experience, major decisions are made and major costs are incurred because some IT specialist or business person has expressed an absolute opinion without recognising that there are possibly other solutions that they have not thought of and that there are experts out there who could solve the problem much more cost-effectively.

Engineers in the physical realm live daily with the above disciplines and accountabilities. It is time for those who have chosen business systems engineering and architecture as their careers to adopt these disciplines as their own.

It is also time for business executives to demand these disciplines from those they contract and employ, and be willing to pay the cost of designing systems and projects that do not fail.