Frank Buytendijk, vice president of research at Gartner Inc, at the firm's Business Intelligence Summit in London said "most organizations are not making better decisions now than they did five years ago."

Some months ago Bloomberg Personal Finance and many other websites reported "BMW Owners Vent Anger at Months-Long Wait for Spare Parts" relating to a SAP Warehouse implementation in which IBM was also involved.

Mark McDonald of Gartner reports "McKinsey Report Highlights Failure of Large Projects: why it is better to be small, particularly in IT"

What is notable about the above reports is that they all originate from highly reputable international sources and relate to mainstream products implemented in leading global corporations, clearly something is not right!

The McKinsey report is interesting in that it recommends small projects as being safer, seemingly oblivious to the reality that the construction industry regularly successfully executes mega projects with little fuss and consistently reliable outcomes.

I live less than a mile from one of many constructions sites on the £16 billion Crossrail project in London that is building a new railway line end to end under London, billed as the largest construction project in Europe at present.  There is little fanfare but consistent reports of steady and reliable progress and no indication of the sort of problems experienced by Bridgestone and BMW.

No one is suggesting that Crossrail should be scaled down because big projects are difficult.

Crossrail also dwarfs the Bridgestone and BMW projects.

So what is going on?

On one hand engineers just get on and make things work, consistently, reliably, day in and day out and we take it for granted that our roads, railways, buildings, factories, etc will be built and will work.  Yes sometimes there are overruns but the level of failure that is at epidemic proportions in the Business Information Systems arena is entirely unthinkable.  If engineering structures failed the way Business Systems projects fail and under-perform we would all be living in wattle and daub structures in the country and riding horses in order to keep clear of the massive failure levels that characterize Business Systems projects.

What to do?

I am a Civil Engineer by training, schooled in the use of computers for engineering applications, coupled to formal qualifications at the Regimental Commander level in the Army Engineer Corps.  As a consequence of a series of unexpected events I found myself involved in running projects to design and implement Business Information Systems.  In the process I gained experience in economics and in general business management as well as working as a practicing Professional Engineer for a number of years.

As I gained more experience with business computer systems I concluded that the business information systems industry lacked engineering rigour and that there was an opportunity to "bring the disciplines of engineering to the business systems industry".

I have been on that journey since 1989 and, in the process have learned a huge amount about what works and what does not work.

Because I had the benefit of never being exposed to the methods and thinking of the business information systems industry, I developed my methods from a first principles engineering perspective built on the fundamentals of the application of computers in rigorous engineering practice and self-taught business computer software design and development methods.

The result has been that my methods are significantly different and my world view of business computer systems is also different and, since they are based on deeply ingrained engineering disciplines and practical experience, I hold them to be better as well.

In 1990, having started out in business for my own account I rapidly came to understand that many IT projects, as we called them then, were failing, in fact about 70% were never commissioned and only about 10% actually met expectations.  Statistics which the Bridgestone, BMW, McKinsey and many other examples suggest are unchanged or worse today.  I started to speak about these statistics at conferences and found myself called in to investigate failed and sub-optimal projects and at times, turn them around.  Accordingly I built up a considerable body of experience.

In 2003 I analyzed all this information and developed what I termed "The Critical Factors for Information Technology Investment Success", I developed a course and wrote a book which is available on my website

Since then I have continued to consult and present courses with regard to these principles.  I have also gained considerable hands-on practical experience in the application of these factors.

Recently I have refreshed the fundamental analysis.

This article is the first of a series of articles in which I plan to share the different facets of this approach and, I hope, afford you the opportunity to take a fresh and better look at the way you relate to business information systems.

Whether projects or your existing operations.

The Factors for Success comprise two elements, the factors that cause failure that must be managed out of the project and the factors for success that must be managed in.  Managing the factors causing failure is, I suggest for your consideration, one of the key differentiators in what is being discussed here.

In this article I will give the headlines and then in the series of articles which I plan for you to receive in the months ahead I will discuss these components in more detail and give guidelines on how to manage them in order to achieve high value outcomes.  Articles in other threads that I intend to publish will elaborate on some of these themes as, for example, the thread relating to Strategic Essence that I started publishing recently.

A fundamental principle of engineering is that engineers do not design for success, they design against failure.  In other words, " engineers do not design bridges to stand up, they design bridges not to fall down".

It is a fundamental principle that a well-designed system that does not fail will succeed yet success is achieved by preventing failure as consideration of any undergraduate engineering curriculum will show.  "Factor of safety" and "probability of failure" are concepts that student engineers learn in the first weeks of their education and spend the rest of their lives understanding how to apply.  This is one reason why IT people struggle to understand engineers.  IT people are prone to hyping up their projects with road shows and flashy presentations, engineers insist on focusing on what is not working and then making it work.

The result?

Engineering structures stand up while companies like Bridgestone launch $600 lawsuits against mega IT companies for failed and sub-optimal project outcomes.  In the process the IT industry focuses on getting better and better at doing the things that got them in the mess in the first place and no one seemingly steps back and questions whether they are getting the fundamentals wrong.

I will leave you to read on and form your own view of whether there is something being presented here that is different from what the business information systems industry practices.  It is my deep conviction that if you engage with these articles and look for what is different not what seems the same, you will find some useful principles that will help you to push your business systems to a higher level.

The percentages in the points that follow are indicative of the relative importance of these factors in my experience and are also roughly indicative of the relative frequency of these factors in causing sub-optimal and failed outcomes.  I plan to discuss each of these items in more detail in subsequent articles:

This is a huge subject.  The business systems industry is rich in mythology, hype and tradition and light on delivery.  Perhaps the biggest myth is a seemingly deep conviction that the current ways of doing things, that have such a poor track record will, one day, if executed really well, turn around and produce different results.

What I term "process obsession" is perhaps the single biggest myth around.

The governance and policies of major business information systems projects is frequently flawed.  Projects which are directed at business outcomes are handed over to the Chief Information Officer to run when, in fact, the Chief Executive as the custodian of the integrated view of the business is frequently the only person with the mandate and the insight to give direction to the project.

The level and mandate of other key project members is also frequently defective.

If you have not read my series of articles on "strategic essence" you might consider doing this now, the full article is available on my website

As the examples in that article demonstrate, clear understanding of the strategic essence of the enterprise and how to translate that into practical components of system configuration, software customization and overall commissioning and operation are vital to successful high value business information system investments.  In fact, without support for the strategic essence your massive high end business information system will be little more than a glorified clerical transaction processing system -- a major factor in why Gartner reports that organizations are not making better decisions.

A major distinction between the average business information system and the average engineering design is that engineering systems are designed literally to the last nut and bolt.  Business systems are generally configured to inexact tolerances with limited or no strategic insight by mid-level personnel on both the implementer and client side who have no grasp of the fact that the precision of the configuration of a system can result in variations of at least a factor of 100 in level of value and performance delivered.  Process obsession is a factor that gets massively in the way of precision configuration much of the time.

"Change management, we do that!" I hear many IT people cry losing sight of the fact that change management as traditionally applied is frequently a blunt instrument to force intelligent staff to do stupid things because the system is badly configured and badly commissioned.  True engagement with the business results in systems that are easy to use, require little training and work consistently and reliably.  Yes, there is a need to train, including training standard methods of working, policies, protocols, etc but I am really talking about system configurations that are harmonized with and flow with the enterprise.

I am also saying that putting in systems to cut head count instead of putting in systems to grow the business with the existing headcount is an intensely negative and massively destructive morale and loyalty destroying practice.

The only reason the Engineering Approach has such a low score is that the other aspects have greater impact and, that said, the rigour, discipline and design against failure of the engineering approach must permeate every element of the project.

Technology is virtually never the problem today and when it appears to be the problem it is generally the consequence of the other factors that are discussed in this article that manifest in bad technology decisions, configuration or commissioning.

Having managed failure out of the project we can now focus on success.

Incidentally, you should have a senior project team member who has as a key project responsibility, to manage against failure.  They should sit in project meetings and listen for the factors causing failure, trap them and manage them off the project.  They should also review all project documentation, ranging from the requirements definition through to eliminating the hype from the presentation to the Board.

The factors, weighted as above, are:

The right organizational executive in charge of the project.  A strong single individual as client project leader.  An equally strong single individual on the implementer side as project leader.  A strategic advisor to the executive sponsor who is not caught up in any other aspect of the project and, above all, NO steering committee!

Simply put, if you boarded an aircraft and found a steering committee in the cockpit I suspect you would run to get off the plane!

The extension of the point on strategy above, work the strategic essence into the entire fabric of the project, the configuration, the customization, the testing, the commissioning and the operation of the system.  Do not allow any person who does not demonstrate a deep and empathetic understanding of the strategic essence to give overall direction to any aspect of the project.  Capture the strategic essence in every validation list, every classification table, the Chart of Accounts

Enable the system to support the organization to do the right things well and thereby to thrive.

Introduce the rigours of standard engineering practice into your project.  Problem is that most engineers do not understand business systems and business and business systems people do not understand engineers so they miss each other totally if you are not careful.

Also be careful as to what type of engineer you engage with and who you commission to brief them and induct them.  Things can go horribly wrong but if you get it right they can go really right.

Precision configuration as opposed to the "sloppy", inexact configurations that commonly occur in business systems are vital.  Your multi-million pound business software system is a precision machine, ensure that it is configured with extremely precise strategic information that is extremely well structured and which makes use of structured code schemes to model the hierarchies and logic in the lists.  I plan to produce a separate thread that will discuss elements of precision configuration.

An engineering laboratory is a place where key parameters of the real world are precisely modelled.  It looks nothing like the real world but it models the real world.  The business simulation laboratory is the same.  It is designed to test the configuration to destruction until it can no longer be broken, then all reports and business intelligence can be developed and tested, workflow can be optimized and embedded, training material can be developed and training can be delivered.  All this in a robust environment to engineering standards which simulates real business operations with war game type exercises that deal with all the exceptions and unusual circumstances.

The final goal is that all staff are fully conversant with the system before it is commissioned to run live in the business, analogous to the exhaustive performance tests that are applied to an engineering system before it is put into public operation.

Business engagement, integration, training, helping people to change, prescribing, configuring and adopting workflow (process) elements, etc.  These flow from the business simulation laboratory as a natural extension of the approach.

Handling the reality that sometimes people do become redundant.

Reliable technology is essential, never cut corners here.  Your goal should be exceptional response times and no compromise should be tolerated.  Do not allow some technology specialist with a mistaken idea that they need to save money here specify your hardware.  Demand high performance and specify accordingly.

The knock-on costs of under-performing hardware, networks, etc not only in terms of direct headcount cost but also morale, accuracy, etc cannot be under estimated.

If you address all the above in conjunction with a high quality technical team who know the software and a high quality business team that know the business and you treat your major investment as one of the most far reaching projects your business is likely to ever undertake you will find that application of these principles will have a huge beneficial impact.

I offer advisory services with regard to the application of these principles and would be delighted to discuss how I might be of assistance.  I also offer a light touch diagnostic service to diagnose the root cause of problems and how to fix them for both operational systems and projects that are not meeting expectations.

Yours faithfully

Dr James Robertson PrEng