One of the key lessons I learned in my journey to learn how to bring the disciplines of Engineering to the IT, ERP and Business Information Systems arena generally was that Engineers do not design bridges to stand up, they design them not to fall down. I realized in around 1998 that during my entire engineering training and practical career I was trained to prevent failure and that this radically different emphasis was key to understanding the methods that I was developing and why the traditional business system and, particularly, ERP implementation methods were fatally flawed.
This understanding underpinned the analysis that led to the course and book mentioned above and the work that I have done since then.
My analysis in 2003 led to me defining “the critical factors that give rise to failure” and “the critical factors for success”. As I have taught and applied these factors my understanding of them has increased dramatically and, in the process, I have refined and adjusted them and adjusted my understanding of the relative importance but the factors have remained essentially the same.
The factors are discussed below at a headline level and I aim to discuss them in more detail in the newsletters that follow.
Since success is achieved by engineering against failure it is vital to first understand the critical factors that cause failure.
The sections below list the seven critical factors that cause failure in my experience. The relative importance in percent gives an indication of the extent to which each of these factors give rise to failure or sub-optimal outcomes. These are not related to the software they are related to what is done with the software and they, not the software, are the things that cause the problems.
There are other lists in circulation but the items discussed here are the fundamentals as I have experienced them over nearly two and a half decades of investigation into failed and sub-optimal project and operational outcomes and I hold them to be well on the way to being definitive. The sequence and reducing percentages do not indicate that the items lower down the list are not important, rather they indicate that if you have a problem higher up the list it does not matter how well you do the things lower down the list the outcome will be sub-optimal.
The percentages are also roughly indicative of the relative frequency of these factors in causing sub-optimal and failed outcomes:
1. Mythology, hype and tradition – 30%
This is a broad category and includes:
Ø failure to realize that different methods deliver dramatically different outcomes with a scale of difference of the order of 100 x between the what is commonly delivered and what is advocated here. Accordingly the criteria used to select an implementer are frequently not appropriate;
Ø industry sales hype that creates masterful illusions that are not real and causes business people to believe that the technology is magic;
Ø outright dishonesty, lies are prevalent, “get the order at any cost”;
Ø failure to honestly own the reality that a weak implementation can do huge damage to the client organization and even put it out of business, Google “ERP failure” to get an indication of the severity of the situation;
Ø failure to engage and empower business executives to engage with and direct the business outcome;
Ø “change of scope” as a camouflage for sloppy and inexact discovery, failure to assist the client to fully understand how the system works, failure to plan for systematic multi-stage elaboration and refinement of understanding of the real long term business requirement and the most effective way of using the software;
Ø manipulating the client to accept the software as it is when modifications are fundamentally necessary in order to fit the business effectively;
Ø “vanilla” is a pod that is used to flavor cakes, it has no relevance to business systems and is a fundamentally flawed metaphor;
Ø limiting scope to the minimum necessary in order to get the job done in order to maximize profits instead of delivering the solution that the business clearly needs and the client thought they purchased;
Ø blame shifting from the implementer to the client, failure to take responsibility;
Ø what I term “process obsession”, insistence on undertaking business process mapping at the beginning of a project when workflow should be prescribed at the executive level towards the end of an implementation and strategic discovery should be undertaken at the start. Process mapping at the start of a project is a low risk way of printing money, it is totally useless in terms of the strategic discovery that is necessary to understand the essence of the business and craft a high value long life solution;
Ø what I term the “audit model”, inexperienced and under qualified consultants on site full day, every day with limited implementer supervision and high billings when the nature of what is required is senior, strategically savvy thought leaders engaged in depth in leading and directing the project with more junior assistants only where applicable;
Ø manipulating the client to take decisions and give direction to implementer personnel in such a way that the implementer shifts responsibility to the client that successful litigation for non-performance is almost impossible;
Ø inappropriate client direction where the client appoints a frequently under experienced and technology focused “project manager” who then gives assertive direction that he or she is not qualified to give and / or fails to manage the things that really matter – this frequently voids any hope of holding the Implementer legally accountable for failure. Contrast this with a very senior strategic facilitator advising the Chief Executive and a business executive as Contract Manager managing the contractors but not the technical direction;
Ø tradition, the ways the ERP / IT industry have always done things and the way they are taught. Because the way the industry has always done things has produced sub-optimal outcomes for decades we see an industry that is getting better and better at doing the wrong things, consider BMW as a case in point;
Ø a widely held view that the implementation of ERP and business systems is the domain of accountants and MBA graduates when it is fundamentally an engineering endeavor and a very highly specialized field of engineering endeavor at that;
Ø mistaken belief that business personnel must understand systems consultants when the correct position is that the consultants must be able to facilitate the business to accurately understand the real issues and make informed decision;
Ø inexperienced consultants with no formal training who should not be near the project in any shape or form, this is a highly sophisticated and complicated field and only highly trained and experienced personnel should give direction;
Ø technology focused consultants who assertively give radically inappropriate advise because they fundamentally do not understand the real issues;
Ø a mistaken belief that the different products on the market are radically different when, in fact, at a fundamental level they all work in broadly the same manner and are differentiated more by gimmicks that often get in the way of sound business solutions than by any leading edge thinking;
Ø a mistaken belief that business systems technology is moving “so fast” when, in fact, the fundamental principles have changed little in the last decade or longer. For example, the basic attributes of a customer have nothing to do with technology;
Ø all sorts of unrealistic expectations and beliefs that have no correlation with the real world. Many of these boil down to a mistaken belief that computers are in some fashion magical and human like resulting in abdication of intellect and responsibility by business executives in diverse components of a typical project;
Ø all of this results in business executives and managers being intimidated such that many keep their mouths shut for fear of appearing ignorant when, in fact, they should take a tough stand and refuse to budge until they have the information they need to take an appropriate, high quality, business decision.
2. Inappropriate or ineffective executive custody, governance and cor-porate policy – 19%
The next most important factor relates to corporate leadership, executive custody, overall project and system governance and corporate and project policies:
Ø on an integrated business information systems or ERP project the only person who is qualified to act as executive sponsor is the Chief Executive. They do not need to give a huge amount of time but they do need to give quality time;
Ø giving custody to other executives or the IT manager is a major factor resulting in completely inappropriate outcomes. Custody to the Chief Financial officer is one of the biggest reasons why operational systems do not interface effectively with the ERP and why the overall configuration is disjointed and requires substantial work by senior staff in Excel;
Ø lack of an executive level advisor to the CEO who thoroughly understands the high level strategic elements of business and who also thoroughly understands business systems and ERP and who has no allegiance or alliances with the software vendors or implementers;
Ø inappropriate overall project governance frequently gives rise to problems;
Ø on occasion corporate policies get in the way of successful outcomes;
Ø and other related factors.
3. Lack of effective strategic alignment and strategic solution archi-tecture – 16%
In 1990 I found that I could not define the term “strategy” concisely and accurately in one sentence and could not locate an effective strategic analysis and design (planning) tool and method. I subsequently developed a tool and method and, having researched the views of McDonald, Porter, Robert and others I concluded that strategy is “the essence of why the organization exists and how it thrives”. This is derived first and foremost from the work of Professor Malcolm McDonald of Cranfield School of Management who asserts that organizations thrive through doing the right things well, my logo is derived from his “strategy-tactics” matrix.
I have repeatedly found that a significant contributor to failure is:
Ø lack of clear definition of the essence of the business;
Ø lack of focus on how the business thrives;
Ø lack of understanding of the fundamentals of the business which can only be determined from effective high level engagement with the Chief Executive and other members of the executive team;
Ø failure to have a senior advisor to the business who understands the above and is able to translate this into the high level solution design;
Ø failure to insist that implementers appoint their best strategic thinkers to work on the project;
Ø failure to engineer strategy and the essence of the business into every facet of the project and configuration;
Ø lack of strategic definition and method results in system implementations getting in the way of the business and hindering or blocking it from thriving. In extreme cases shoddy implementation can destroy an organization and put it out of business.
4. Lack of Precision Configuration – 14%
In other words, what I call “sloppy configuration”.
Over the years I have come to understand that computer based systems rely heavily on intelligence in the data and I have developed an overall approach to configuration that I now refer to as “Precision Configuration”. The absence of this component is the biggest single consequence of sub-optimal actions on the preceding three factors. It is also the hardest legacy of a badly run project.
Lack of Precision Configuration includes:
Ø badly structure or unstructured Chart of Accounts, product classification, employee classi-fication, service classification, etc;
Ø lack of strategic logic in the Chart of Accounts and other tables mentioned above;
Ø badly thought out codes, consecutively coded when they should be gap coded, etc;
Ø failure to define all possible attributes on master files;
Ø failure to ensure that lists are hierarchical in order to reflect the logic of the organization;
Ø failure to make lists easy to read and interpret including failure to take account of cognitive span;
Ø failure to define lists from a comprehensive, holistic, long term, executive information and decision support perspective first and foremost;
Ø failure to design on the basis that the most fundamental executive requirement is “answers to the questions I have not yet thought to ask”;
Ø failure to design the configuration with a five to ten year future focused view of where the business is going;
Ø failure to identify the need for strategic customization building on the precision configuration in order to maximize business effectiveness and efficiency;
Ø failure to create a platform that will support a sustainable high value solution;
Ø failure to design the configuration for ease of reporting, analysis, dash-boarding and operations;
Ø diverse other factors that together result in a configuration that compromises the effec-tiveness of the business.
5. Failure to address soft issues, business engagement and change impacts – 12%
When I started out in what I do today, in 1989 I was, as an engineer, very unaware of the soft, that is psychological, issues of change. I had achieved business engagement unconsciously and had managed change impacts through a high level of Chief Executive engagement. I very soon learned that these ideal conditions were not prevalent and that there were major problems associated with managing organizational change.
Over the years I have come to understand that these issues include:
Ø motivating projects on the basis of headcount reduction and therefore alienating staff is totally inappropriate and highly destructive. This mobilizes staff to actively or passively resist and even sabotage the project;
Ø illogical and badly design configuration that staff resent because it is so sloppy;
Ø executive abdication ripples down through the entire organization. If the CEO does not think this is important, how do I motivate myself?;
Ø consultants taking on roles that business management should be playing;
Ø failure to engage with the right people in the business at every step of the project;
Ø failure to get the right people around the table in every workshop and on every component of the project;
Ø failure to recognize change impacts resulting in the project blundering into toxic psychological behavior;
Ø active and passive sabotage including key personnel ensuring their job security;
Ø poor or no project communication;
Ø incompetent consultants;
Ø diverse other human behavior and psychology related factors;
Ø “change management” that is actually a blunt instrument for beating client personnel into submission when they resist the above factors.
6. Lack of an Engineering Approach – 6%
As an engineer, when I use the term “engineering approach” I am not using “engineering” in the loose and imprecise manner in which the Business Information System Implementation industry so frequently misappropriates terms they do not understand from other specialties. I am using “engineering” in the sense of what was instilled in me by leading engineers of the highest caliber in the formative years of my professional development. A profession that solves problems designs and constructs solutions to the highest standards of rigour, precision, accountability and professional dignity.
A profession that designs and builds things that work, bridges that stand for centuries, aircraft that fly year in and year out with minute accident figures, factories that work and work and work, buildings that function effectively, etc. A profession that regulates itself and has chosen to be regulated by statute and which has an exceptionally low tolerance for professional incompetence and negligence.
When I use the term “engineering” in the context of the business systems industry I am referring specifically to the implementation of the systems and not to the construction of the software. Remember, only 3% of what causes failure relates to technology and part of this relates to hardware, networks and related issues.
If you research the situation at BMW in the period up to September 2013, as referenced above, you will find references to “only 5%” and “will be rectified by the end of September”. The fact is that thousands of vehicle owners and many service businesses were badly detrimented by the situation.
Once you understand the concept of an “engineering approach” you will understand why the situation at BMW points to negligence and / or incompetence by some persons involved in the project.
Society would not tolerate a situation in which “only 5%” of aircraft crash, or in which they were assured that aircraft would cease crashing within a month or two.
BMW have undoubtedly suffered reputational damage to their brand that will take time to rectify. If the situation is not rectified soon this will escalate dramatically. The fact that, as at the time of writing, 3 October 2013 there is no formal announcement by BMW that the problems have been solved, suggests that they are still occurring and the promised 30 September 2013 deadline may not have been met.
It is also noteworthy that, following a flurry of reports, there appears to be total silence on the BMW situation. This suggests that one of the other attributes of the ERP and business systems industry is hard at work – silence. I was once instructed by a client, after I had established that their SAP R/3 implementation was so seriously sub-optimal that it would need to be scrapped and re-implemented from scratch not to use the phrase “re-implement” so that the shareholders would not learn of the situation. We were to refer to the situation as a “re-alignment”!
In engineering any failure is immediately comprehensively analyzed by objective third parties and the causes fully documented and openly published in order to prevent recurrence. Consider the “Air Crash Investigation” series on TV as an example. Another example of the difference between the business systems and ERP industry and the engineering world.
By Engineering Approach I mean a highly structured, meticulous, systematic, rigorous approach derived from the formal disciplines of Engineering that are instilled in Engineers from the earliest days at University.
In terms of the lack of an Engineering Approach, projects fail because of a lack of:
Ø accountability, implementers make promises in ways that they cannot be held accountable. They also execute projects in a fashion that shifts almost total blame to the client;
Ø failure to rigorously define the requirement in business outcome terms and enforce compliance with this specification;
Ø failure to undertake a rigorous, thorough and tough tender based procurement process directed at achieving a tough contract;
Ø failure to discuss and understand failure and manage failure out of the project throughout the entire duration of the project. That is, failure to engineer against failure;
Ø failure to employ personnel with formal engineering training and certification and appropriate business and systems experience;
Ø the audit model of project operation versus the construction model;
Ø failure to plan and / or design and / or execute in meticulous and rigorous detail;
Ø failure to use simulation to comprehensively test the configuration to destruction until it does not fail any longer. That is “break it till you cannot break it any more”;
Ø failure to use sampling techniques to ensure that test data is representative of every possible scenario in the business and is also selected in order to deal with extreme events with a view to breaking the configuration and ensuring that the entire set-up functions reliably before commissioning;
Ø failure to operate a formal “Business Simulation Laboratory” and run all aspects of system operation through the laboratory prior to authorizing commissioning;
Ø failure to fully test the entire configuration, reports, etc in the laboratory before authorizing commissioning;
Ø failure to fully train all personnel in the laboratory before authorizing commissioning;
Ø failure to employ a rigorous, certificate based approach to authorizing commissioning that includes penalties;
Ø failure to manage the deployment of the solution as an engineering endeavor;
Ø failure to do the things that an appropriately trained engineer would do instinctively to “make it work”.
7. Technology Issues – sub-optimal or defective software, hardware, network, etc – 3%
As you will see, technology is only 3% of what causes failure today.
That said, if you do have a technology problem it can wreck the entire project. Some years ago I advised a client with an extremely badly configured network that was massively consuming bandwidth. This resulted from inappropriate network traffic and poor network configuration to the point that it was taking two minutes in a remote office from the time the “Accept” button was clicked with the mouse to the time when the next screen form was painted. The system was effectively totally useless and the business was being run in Excel outside the big brand ERP.
So, technology can be an issue, although in this case the problem stemmed, in fact, from inappropriate governance, the project and the IT department reporting to the Legal Affairs director.
Technology factors include:
Ø under capacity hardware;
Ø under capacity network;
Ø unreliable hardware or network;
Ø badly written software, the factor that most people blame for poor system performance but which is very seldom the cause;
Ø gimmicky and badly conceptualized software that gets in the way;
Ø etc
This is not the place to cut corners. As rule of thumb most people should consider the hardware budget to be overly generous. The moment hardware is purchased on a tight budget without a clear understanding of the dynamics of the technology it gives rise to problems.
Underperforming hardware can cause total project failure and massive business damage, if in doubt, spend more. Generally the Financial Director is the wrong person to set the hardware and network budget.
Most of the time, as in the BMW case above, the problems stem from other factors higher up on this list.
These are the factors that cause failure; they must be managed out of the project and the operation of the system.
Please contact me on James@James-A-Robertson-and-Associates.com to find out how I can assist you to apply the principles discussed in this article