Case Studies: Articles examing Business Information System failures

Case studies of publicly known Business Information System failures with a view to drawing out the lessons to be learned by applying the methods and principles advocated by Dr James Robertson to such projects

Case studies with regard to successful projects that I have been involved in are contained in the Articles database and also under the Precision Configuration menu option

<<< PREVIOUS SECTION: IT Effectiveness

<<< PREVIOUS SUB-SECTION: Critical Factors for I.T. Success

NEXT SECTION: Speaking and Training >>>

NEXT SUB-SECTION: The BBC Digital Media Initiative Debacle >>>

The BBC Digital Media Initiative Debacle

The Bridgestone -- IBM Conflict

Critical Lessons from the BBC DMI Debacle

A brief analysis of the failed BBC DMI project advocating that such projects are fundamentally of an engineering nature and should be managed accordingly and that there is great need for Government to introduce statutory controls on the conduct of the Business Information Systems industry

What is noticeable about the BBC’s failed Digital Media Initiative (DMI) is the comprehensive reporting of management failure to manage effectively and management’s apology to the public.

What is noticeably absent is any comment on the performance of the suppliers, Siemens who presumably were supplying the physical technology or the performance of any of the supposedly professional service providers, who consumed the £125.9 m (before recoupment).

The breakdown of expenditure is instructive:

Contractors - £46.7m
IT - £37.2m
Siemens costs - £24.9m
Consultancy - £8.4m
BBC staff - £6.4m
Other - £2.3m

There is NO reference to a prime contractor, only “contractors” which seems to suggest that these were individuals NOT a large computer systems contracting entity. There is also reference to “Consultancy” but no reference to which firm or firms and then “IT” presumably applies to other computer technology not supplied by Siemens – overall an interesting mish-mash that already points to the reasons why failure occurred. Not that having a large IT company like IBM necessarily guarantees a better result, as BMW (BMW owners vent anger at month’s long wait for spare parts – Bloomberg)_ and Bridgestone (IBM Rips Into Bridgestone Over $600 Million Lawsuit – Business Insider) have both learned in the recent past.

And the fact that IBM have seemingly walked away from BMW unscathed, in its own way, offers an interesting insight into the business computer systems industry, an industry characterized by more high profile investment failures than ANY other area of human endeavour in the commercial arena.

While these major IT failures are taking place the Crossrail project in London with its 10 new stations and 21 kilometres of twin railway tunnels under the centre of London dwarfs these projects in scale and complexity, yet the most superficial inspection indicates that the tunnels are where the designers said they would be and they line up with the stations. Further, global experience with projects of similar complexity indicates that Crossrail WILL deliver what it said it would, more or less on time and more or less on budget and, even if it does go over budget and deadline it will still work as planned.

So, what is different?

Ø Large highly specialized contractor organizations with a track record of delivering;

Ø Large highly specialized design organizations with a track record of delivering;

Ø A close to zero social tolerance for failure of projects of this nature;

Ø Statutory regulation and corresponding professional regulatory bodies that prevent inadequately trained and inexperienced engineers and technicians working on such projects and which impose harsh sanctions for incompetence or negligence.

“Incompetence and negligence?’ – YES! Ultimately the failure at the BBC has to be the consequence of incompetence and negligence, amongst other factors – incompetence being the lack of knowledge and experience necessary to successfully execute a project of this nature and negligence because it is negligence to embark on a project of this nature without the technical certainty that you know what you are doing and have the necessary checks and balances in place to ensure a successful outcome. Notice that I say “ensure a successful outcome” NOT “fluke a successful outcome” – success is the necessary consequence of a systematic, disciplined and informed engineering endeavour that is designed NOT to fail. Failure is the inevitable consequence of incompetence and negligence.

There is a fundamental principle that should apply in a case like the BBC’s failed DMI project in order to prevent failure – there should be a lead solutions architecture company conceptualizing and framing the solution design; a lead systems engineering company designing the solution; and a lead solutions construction company building the solution. All three of these organizations should deploy teams of highly experienced personnel with formal training and certification in the disciplines necessary for engineering solutions of this nature. And there should be tension between these three organizations, because all three (but particular the solution architecture firm) should be looking out for the best interests of the client.

“But!”

“Engineering!!”

“James, this is the IT industry, NOT the engineering industry!”

That is precisely the point.

The design and development of systems of ANY sort IS an engineering endeavour

The American Engineers' Council for Professional Development has defined "engineering" as “The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.” (Wikipedia)

This is EXACTLY what the BBC embarked on with DMI, the engineering of a solution for managing their digital material.

The fundamental problem is that they failed to embark on the project as an engineering project and they failed to use engineers to manage the project.

But there IS a catch and that is that engineers do NOT know how to manage this sort of IT project and so, if you let engineers loose on their own, you get problems as well.

You see, Information Technology projects are extremely abstract. They involve software that is effectively invisible working with human beings who are for the most part, unstructured and work in unpredictable ways and there are many other complexities such that “IT Mythology” constitutes 30% of why such projects fail – IT Mythology is the mistaken belief that computer systems are in some sense magical and work on their own, provided you sort of hack it, see my website for a discussion of this and the other factors that cause IT investment failure.

What is particularly notable about the reports concerning the BBC’s DMI project crash, like so many project crashes of this nature, is that there is NO evidence of any professional body or statutory body investigating the failed project in order to establish what went wrong and to develop policies, disciplines, training material, licensing requirements and other safeguards in order to prevent recurrence – there is NO “air crash investigation” to cite the popular TV documentary.

There IS a report by PriceWaterhouseCoopers which finds “"PwC has concluded that weaknesses in project management and reporting and a lack of focus on business change... meant that it took the BBC too long to realise that the project was unlikely to deliver its objectives," it said in a statement” – this hardly points to a rigorous and tough engineering root cause assessment of why failure occurred! But then PWC are NOT an engineering company and they are deeply involved in the IT industry themselves with their own history of failures, so hardly in a position to deliver an objective assessment of the situation.

What I am referring to is a statutory body with teeth and the willingness to call a spade a spade and name incompetence when it encounters it.

In fact, there is NO indication of any intention to establish such a statutory body or such a professional body, presumably because it has NOT yet occurred to government that they have an obligation to promulgate such legislation and institute such controls. And the industry is in part too fragmented and in part making too much money out of failure to care about doing anything about the situation. After all, of the order of 70% of IT projects fail outright, as in they never see the light of day, and a further 20% materially fail to meet the requirements of the customer, partly because 70% of the components of the 20% are a total failure. This leaves us with 10% of all projects that at some material level meet client expectations and even then the indications are that less than 5% of ALL projects MEET or EXCEED the expectations held by clients at the time that the project was authorized.

So the IT industry is enormously wealthy in significant measure out of gross inefficiency and incompetence – after all, if 70% of projects die before they see the light of day it is easier to bury them quietly than to make a fuss about it and expose one’s failure to one’s shareholders and competitors let alone a drubbing from the Public Accounts Committee.

Until government and industry join forces to form a body to fully dissect failures of this nature AND establish suitable professional training, certification and licensing of consultants and vendors, the carnage will continue. Attacking and condemning the responsible executives is well and good, but if they have NO resource to prevent such failures failure WILL continue to be the norm!

I have been investigating and documenting the causes of business information system failure and what is required to prevent failure from an engineering perspective for 25 years. I formally published my findings in 2004 and have been applying these findings since then. The challenge is for someone with influence to decide that failures of this nature are NO longer acceptable and start the ball rolling to produce legislation introducing strict and onerous regulation of the business information systems industry and its practitioners.

Such failures as the BBC’s DMI project are ENTIRELY preventable and high value successful outcomes are ENTIRELY achievable.

Dr James Robertson PrEng

The BMW ATLAS SAP EWM project -- spare parts delivery problems -- an illustrative example of the factors causing failure

To illustrate how these factors work in practice I would like to return to the BMW situation referenced at the start of this article, visit http://www.bloomberg.com/news/2013-08-27/bmw-owners-vent-anger-at-months-long-wait-for-spare-parts.html for details.

Google “BMW Owners Vent Anger at Months-Long Wait for Spare Parts” for many more reports.

Ø The product was the SAP Extended Warehouse Management Software (EWM);

Ø The client was BMW’s main spare parts warehouse;

Ø The implementation consultants were IBM who have reportedly walked away;

Ø The system ran live and immediately there were problems with fulfillment such that reports indicate customers around the world have been waiting for months for repairs;

Ø BMW have been seriously embarrassed, their reputation has been tarnished and, if the problem is not definitively resolved soon, material damage to the brand may well result;

The fact that a superior engineering organization such as BMW, installing a supposedly world class product from one of the leading software suppliers in the world, SAP, and assisted by an implementer of the stature of IBM cannot get it right first time should cause all potential purchasers of any form of Business Information System to look seriously at what is presented in this article and seek to apply it rigorously.

I contacted the CEO of BMW some weeks ago to offer my services to assist him to identify the root cause of the problem in line with the principles set out above. I received a response from the executive responsible for after sales service and from the project manager and my offer was then declined. I again approached the CEO and this time received a reply from the person responsible for internal consulting who rather curtly told me to go away.

All three replies demonstrated a complete lack of understanding of the issues that I was raising and, in my opinion, gave a basis for serious concern. I again approached the CEO and have received no reply.

However, from this interaction I have been able to draw some headline inferences which help to demonstrate the relevance of the approach advocated above:

Ø the CEO passed the inquiry on to one of his executives who then passed it on to the project manager à immediately a problem with executive custody at both levels;

Ø the nature of the problem, only some parts are being delayed, when, based on the outcry, with the old system they were fulfilled timeously à indicates that there are problems with the configuration at the level of inaccuracies in the master data, something has not been set up correctly, fundamentally a lack of precision configuration, a human discipline problem;

Ø furthermore a level of irony, the car is in the ditch and it can only be there because of negligence or incompetence on the part of the driver or the support crew but the offer to investigate is passed to the two people who must surely be most accountable for the mess à indicative of a lack of understanding, “we think the machine is not working correctly”, but computers do what they are told and it is unlikely that the problem results from the machine, in other words mythology or someone somewhere might be lying;

Ø the project manager wanted me to have expertise with regard to the software and the industry. The car is in the ditch because of bad driving but the accident investigator is turned away by the driver and the team manager on the grounds that the accident investigator does not know the engineering details of the engine in the car and of the straight, four lane highway on which the car crashed à mythology or a lack of Engineering Approach in the form of accountability;

Ø the email response from the responsible executive spoke repeatedly of “business process” as though somehow the new system had exposed massively defective business processes that had been lying latent waiting to be exposed. Problem is that the parts were being fulfilled before the new system was commissioned, judging by the irate complaints of service centers and customers à mythology and tradition or someone is lying to the executive concerned;

Ø clearly there was no Business Simulation Laboratory, if there had been there is no way the system would have been allowed into production;

Ø clearly the “Engineering Approach” was weak or absent, if there had been there is no way the system would have been allowed into production.

These are the most obvious inferences that can be drawn from press reports and my interaction with the company.

From Here:

<<< PREVIOUS SECTION: IT Effectiveness

<<< PREVIOUS SUB-SECTION: Critical Factors for I.T. Success

NEXT SECTION: Speaking and Training >>>

NEXT SUB-SECTION: The BBC Digital Media Initiative Debacle >>>

Random Selection of Articles by Dr James Robertson

Std 027 COBOL – old software CAN be retained (with reference to Bridgestone)

Many organizations replace COBOL systems because they have been told they are obsolete, this article dispels that myth

Std 011 Procurement: 03 Business Information System Requirements Definition

The Business Requirements Specification is a strategically focused document, that is it lifts out the essence of the business and how it thrives in a structured and weighted manner so that there is NO uncertainty on the part of the bidders as to the exact nature of the business

The strategic essence must lift out the fundamentals of the busines and particularly what is unusual, the elements that deliver competitive advantage and which are therefore the most vulnerable to inappropriate action

This is NOT the place for generic industry definitions or for long lists of standard software functionality -- development of the requirements specification requires a mature and highly experienced consultant with a solid understanding of strategic essence AND a solid understanding of systems and how systems integrate with the business to deliver high value outcomes

CIO 010 Is I.T. Really Moving "SO FAST we cannot keep up with it"?

Cnf 087 Critical factors for strategic business improvement success

A discussion of the factors that give rise to general business improvement success drawing on my experience with business information system and ERP projects

Std 013 Procurement: 05 Software Schedule

The software schedule is a list of all functional software elements that it is assessed are required. This is a basis for bidders to add and subtract the modules and products that they have to offer in order to make up the mosaic that constitutes the complete response to the requirement

The software schedule correlates directly with the Bill of Services and the two should be set up to align with one another

CIO 002 It's about People

SNw 049 Strategic Essence: The Missing Link: Part 4 -- The Essence should be the Point of Departure

The strategic essence of the organization should be the point of departure AND the focal point of every business information systems project -- THIS is the component of the business that should be jealously protected, strengthened and enhanced and it is the part of the business that is most vulnerable to bad decisions and botched projects

Prd 033 Why would an Executive buy the JAR&A Analytical Financial Suite

SNw 028 Thrive = right information + right decision well executed

Std 005 Procurement: 00b Invitation to Bid

A simple invitation letter which you can tailor and elaborate on as you see fit

Dr James A Robertson PrEng

Business Systems NOT delivering?

Call the Business Systems Specialist

Dr. James Robinson

Dr James A Robertson -- has been involved in the effective application of Business Information Systems, including but NOT limited to ERP, since 1987 and in the profitable and effective use of computers in Business since 1981.

Drawing on a diversity of experience, including formal military training in Quick Attack techniques at the Regimental Commander level, Dr Robertson has developed highly effective methods of investigating any sub-optimal Business Information Systems situation -- be it an established system or a stalled project or any other source of Executive frustration -- quickly and concisely diagnosing the root cause of the problem and prescribing concise practical actions that Business Executives can effectively act on see the Pulse Measurement page and also the Sample Reports page for redacted real reports.

He has also developed highly effective methods of strategically enriching systems to unlock the full potential of existing investments, see the Precision Configuration page and couples this to architecting small pieces of clever software that harness the full potential of your investment, see the Software page.

If you are having problems with your systems, your project or your IT Department, call The Business Systems Specialist
James@James-A-Robertson-and-Associates.com

Business System Failure is RIFE -- we offer insight into why this happens AND WHAT is required to prevent it.

Failure is at epidemic levels with massive damage done to client companies -- if you are NOT aware of the extent of the problem please visit the About Failure page for a catalog of major failures running to billions of Pounds and Dollars.

All evidence indicates that the established players do NOT know how to deliver stable, reliable high value solutions that WORK.

There HAS to be a better way!

This website provides information relating to that way with a large collection of white papers, presentations, standards documents, etc that you can use to start bringing the situation under control

We also offer high level advisory services with regard to the application of the principles advocated on this website

We offer an ENGINEERING APPROACH to addressing these issues

By Engineering I mean the formal, structured, highly disciplined, highly systematic, highly practical approach that consistently delivers results in ALL areas of human endeavor where formally trained and certified engineers are the ONLY practitioners permitted to operate -- think large buildings, factories, motor vehicles, aircraft -- highly complex systems that work at a level that we take it for granted that they WILL work and where failure is all but unthinkable and, when it happens, attracts immediate public attention and rigorous investigation directed at ensuring that such failures are prevented in the future -- in fact, everything that the management consulting industry that implements complex software systems is NOT

This approach is discussed further on the Engineering Approach page.

Search Articles

Book -- The Critical Factors for Information Technology Investment Success

In 2003 I undertook an in-depth analysis of all the information and experience that I had gathered with regard to the factors giving rise to Business Information System failure including ERP and general IT and classified this information into a number of categories including "The Factors Causing Failure" and "The Critical Factors for Success" based on this I developed a two day Course "The Critical Factors for Information Technology Investment Success" which is still offered today.

Based on this I wrote the book of the same name, which is available in electronic form here for download:

Random Selection of Articles by Dr James Robertson

Civ 002 The essence of sustainable wealth creation

Cnf 053 Engineering Maintenance Management Methodology With Radical Rethink About Clinical Data Code Design

The current clinical data codes, ICD 10 and CPT 4 are exceptionally weak as information classification, management and analysis tools and massively inhibit the creation of clever clinical and medical software, there is a huge opportunity to redesign these codes and use the resulting intelligent codes to develop very sophisticated health management systems drawing on engineering maintenance management and other techniques in order to provide solutions for areas and countries with a limited number of healthcare practitioners

TxM 058 Section 7.2 The opportunity

TxM 024 Section 2.7 Defining the taxonomy approach

Std 024 The ART of Strategic Business Information System Project Leadership

The general tendency is to think in terms of Project Management for business information systems projects and the reality of many business information systems Project Managers is that they are administrators rather than strategic leaders. This article discusses the role of the Strategic Business Information Systems Project Leader as effectively an interim executive who reports directly to the Chief Executive and acts as an advisor, agent and proxy for the CEO in managing the entire integrated business information systems project to achieve a high value business outcome

TxM 018 Section 2.1 What is the JAR&A Strategic Engineered Precision Taxonomy (SEPT) approach?

Cnf 018 Designing and Implementing an Integrated Risk Management System

A small, rapidly designed and built loss management software solution with accompanying Precision Configuration built and deployed in a matter of a month delivered very substantial strategic management information value together with unexpected dramatic efficiencies

SNw 045 Strategic Essence: The Missing Link: Part 3 -- The Essence IS Different

The strategic essence of the organization IS different, it is unusual, the competitors have different strategic essence or manage it differently, IF the organization is of any size and has been moderately successful then there are some KEY things it is doing that are unique and different

TxM 064 Section 7.8 Categories of lists

Cnf 078 The New South Africa -- Why Engineering Fails

Technology failures are the consequence of human error or negligence, the presentation discusses the fundamental reasons why technology projects fail in the context of the requirements of engineering in the New South Africa