Is there a systems engineering silver bullet? In Part I of this two-part series, I described the criticality of high-quality tools and processes but cautioned that they are not a guarantee of success. They are not a silver bullet. Engineers must still apply engineering rigor for projects to be successful. In this post, Part II, I look at what is essentially a failure of the imagination: the danger of super-imposing old solutions onto new problems.
In the middle of my career, I worked for customer service management software companies. During that time, I was exposed to a broad spectrum of projects, and I have continued to maintain an educated understanding of that market. A segment of particular interest to me is the Enterprise Resource Planning (ERP) market. What interests me most as a systems engineer looking at ERP is why this marketplace has such epic failures. There are countless articles and case studies that discuss the causes. Take, for example, this article published by Bista Solutions: Ten Reasons for ERP Implementation Failures. In it, the author outlines a few significant failures that provide context:
The horror stories of failed ERP projects are now the stuff of legend. According to one recent report, more than 29% of ERP implementations fail to achieve even half the planned business benefits. Some well-known examples include Waste Management suing [company] for $500 million for a failed ERP implementation, Hershey Foods’ 19% drop in profits from a failed [company] implementation at Halloween time a few years ago, the complete bankruptcy of FoxMeyer Drug, a $5 billion pharmaceutical distributor over a failed $100 million ERP implementation, and, perhaps most troubling, the over $1 billion spent by the US Navy on four different ERP systems, all of which have failed.
The article identifies ten reasons why these projects fail. In my opinion, the high impact failures are systems engineering failures. Of the ten, I highlight four as being particularly important:
- Doing it in the first place
- No clear destination
- A good plan, or just a plan?
- Customization
The first three are self-explanatory, but what isn’t so obvious and results in extremely devastating failures is the impact of customization.
The article recognizes and cites customization as a problem. In my experience, that doesn’t touch on a fundamental issue. Organizations typically identify a host of changes and customizations that they want. The question is why do they want them? Is it to make the new system exactly the same as the old? If so, why is the project being implemented? Enterprise Resource Planning suppliers, much like systems engineering software providers, expend numerous development years creating infrastructure and identifying best practices that they then implement in their tools. Organizations, instead of asking how to change the default software environment to match their old processes, should investigate why the software does what it does and why it does it the way it does.
Another key why question is: Why not use the default? What is so unique about the way you do business? After all, you may realize that, “We’re experts in the XYZ market segment just as tool vendors are experts in their domain, so why not take full advantage of all of the operational research they’ve done to leverage our success?” When adopting a new environment – be it ERP or systems engineering – the value is not only in the software capabilities. There is value in understanding the mental model and approach embodied in the solution you have chosen and leveraging that approach to the maximum degree possible.
If one does the analysis and chooses the path of customization, be aware that there is a cost involved. Once customizations are made, they need to be tested and maintained, potentially forever. Even seemingly successful customizations can perpetually cause pain. In a linked or distributed environment, retesting will be required at each linked project software release. In some cases, the scope of testing may be so great an undertaking that the end result may be an inability to upgrade one or multiple development environments.
We engineers often think we know a better way to do things. This includes me. As a result, we don’t limit our scope of effort on the project. We add in tool development, thereby adding unnecessary cost and risk to our projects. It’s a fair question to ask – are we in the business of engineering and maintaining our tools or are we in the business of engineering the systems we deliver? Often, as engineers we may derive enjoyment from building or tailoring tools but at what cost?
In these posts, I hope I have conveyed two key things. The first is that tools and processes don’t replace good engineers (Part I). The second is that when we evaluate, choose, and use systems engineering tools, we need to try not to reinvent the wheel. We need to judiciously evaluate what the tools do, use them for what they do well, and then try as hard as possible not to customize the tool. If you ultimately determine that the default tool can’t do something absolutely critical, contact the vendor and inform them of your problem. They may already have thought about that problem and have a solution or be able to propose a very supportable work-around.
Good luck, and happy engineering!
