Cubic Corporation invested in an ERP system to streamline operations and improve profitability. More than two years later software and implementation costs are over $61 million and climbing. Is this another ERP boondoggle?
Based in Southern California, Cubic Corporation is a public company that operates in the defense and transport industries. In February 2015 the CEO announced steps to streamline operations and improve profitability, which was expected to yield about $16 million annualized pre-tax savings in the financial year 2016. This would be about $160 million savings over 10 years.
The ERP project was started in late 2014 and was expected to be completed by the end of 2015. But as of mid-2017, the implementation was still going strong. Based on published financials, as of March, 2017 Cubic had spent $61 million on the project so far. With completion currently estimated to be in 2018 (assume Q2) and extrapolating implementation costs, Cubic will have spent a total of about $86 million on their new ERP software project by the time it goes live.
Enterprise software implementations usually take substantially longer and cost more than planned. When going live they often cause major business disruption. Here's a look at the root cause of the problem, with suggestions for resolving it.
Whether it is in the cloud or the data center, so often enterprise software takes much longer to implement than expected. There are three main reasons for this.
1. Unknown requirements
New requirements are discovered during implementation that should have been found during the analysis. When these new requirements are found, the organization must decide what to do with them. If they are weighted as important or higher, the consultants must determine how to implement them: by configuration, writing code, business process re-engineering, or adding new modules or third party products. All of this takes time, and when too many new requirements are found implementation schedules slip.
Ambiguous requirements can lead to purchasing software that doesn't meet expectations. Here are some simple techniques for avoiding ambiguities in your requirements.
Adequate and well-written requirements are the foundation for selecting enterprise software that meets expectations. A common problem with requirements is that some of them may be ambiguous. While ambiguities are easy to see in requirements written by others, they are difficult to spot in your own writing. Ambiguities cause problems selecting software in cases such as these:
It’s the unknown unknowns that get you every time! Learn how to identify unknown software needs, and then evaluate the urgency and importance of satisfying them.
While internal growth can drive companies to make major software purchases, another driver is external growth. Internal growth refers to a company growing organically through new customers, by mergers, acquisitions and so on. External growth refers to a company operating in a growing environment or a growing market, and is occasionally described with the phrase “A rising tide lifts all boats.”
Marketing technology is one such example of a growing environment, and it is spectacularly illustrated by Scott Brinker and his annual Marketing Technology Landscape Supergraphic. In 2011 he listed about 150 marketing technology companies on a single page in graphical format. Scott has updated this graphic annually, and in 2017 it contained 5381 products from 4891 companies. For several years there was an astounding 100% annual growth, although in 2017 it had tapered off somewhat.
In the corporate world many decisions are made in meetings, but too often things fall between the cracks. Here's a look at how a San Francisco law firm used new Workboard OKR software to solve the challenge of getting things done.
Even with the best will in the world, it usually takes too long to get things done in corporate situations. Meetings are a primary way in which goals are decided and agreed upon, but they consume inordinate amounts of time when you consider things like developing agendas and PowerPoint presentations, meetings that run over schedule, and the need to have some meetings again because you can’t remember commitments. Some things always seem to fall between the cracks, and results take too long to achieve. Workboard aims to solve this problem in a new way. To find out more, I interviewed Workboard CEO Deidre Paknad.
See how poor requirements analysis puts enterprise software purchases at risk of partial to outright failure...and how to fix the problem.
There are multiple reasons why major software purchases fail, but one of the most common is that of an inadequate requirements analysis. The problem is caused by people being unfamiliar with requirements gathering techniques, and by grossly underestimating the amount of work involved.
Requirements are to software selection as foundations are to a building. Get them wrong or leave things out and there always will be problems. This article examines the consequences of missing requirements in the analysis phase and describes how to avoid the problem in the first place.
In spite of the time and money spent, few software deployments meet expectations. Why? This article examines common reasons why selecting software is so difficult, so these problems can be avoided.
Successful software purchases meet or exceed expectations; failures do not. Failures vary in degree from benign -- e.g. those that are delivered late -- all the way through to outright failures where the new software is dumped and the project may be restarted.
In this article, we look at common factors that make purchasing enterprise software so difficult. Being aware of these difficulties before starting a project can help you reduce their corrosive effects on the success of your next enterprise software acquisition.
Think of business process management software as 'the oil that lubricates corporate machinery.' With dozens of options on the market, use the reverse-engineering technique to find the BPM system that best meets your particular needs.
While enterprise applications like ERP, CRM, HRIS and others cover their respective domains, business processes often need information to flow between these systems. An organization may also have specific processes that are not well handled by these enterprise applications, for example, unstructured or partly structured processes, or those touched by people outside the organization. The last thing you want to do is to customize application code to handle these types of processes because that makes upgrades difficult, risky and expensive. Another problem is that enterprise applications may not be easily adapted to changing business conditions.
To handle these situations, you may want to consider business process management (BPM) software. BPM could be seen as the “oil that lubricates corporate machinery,” allowing workflows to span multiple systems, coping with semi-structured or unstructured processes and allowing highly business specific processes to be built and maintained.
Many people think process analysis and optimization should be done before embarking on a software project. This article explains why it is unnecessary when buying cloud or commercial off-the-shelf software.
When an organization wants to improve operations, they can be faced with the choice of buying software or writing their own. If they decide to write the software themselves, early phases of the project involve business process analysis and optimization. However, writing software is an expensive and risky proposition for most organizations. Sometimes they can’t even finish what they start; for example see "An IT failure unicorn: Endless 19-year project in Massachusetts" by Michael Krigsman. If suitable software exists, it is usually far cheaper and less risky for an organization to buy the software than to write it themselves.
Collecting detailed software requirements from users is difficult. See how rewriting software features as requirements helps develop a comprehensive requirements list for selecting enterprise software.
When buying enterprise software, conventional wisdom says that users are the ultimate source of functional requirements. While this seems logical, it is incomplete because, apart from their pain points, few users know what they want from the software. The question is why does this happen and what can you do about it?
Why users can’t articulate their requirements