Don’t Be Left Out In The Cold

A recent article in The Australian Financial Review covered the demise of Scott’s Refrigerated Transport. The sub-heading said, “A badly timed IT upgrade led to pallet and delivery chaos.”
 
While I was not involved in this upgrade, I have some personal insight into that project and company as I worked on the original implementation when AHG owned Scott’s. That project taught me much about the ERP industry, and I’ll share my thoughts and lessons below. If you take one thing from this article, let it be this – IT failure is rarely the code’s fault. It is almost always a human issue compounded by corporate cultural issues.
 
My thoughts on the article and project are as follows:

• Scott’s Transport’s original implementation of Microsoft AX 2012 was part of a more extensive portfolio of work undertaken by AHG, who owned the business then. AHG was being advised and, in many cases, directed by a big, and so-called independent, consulting firm filled with ex-Deloitte executives.
  
• Based on the advice from their advisors, the same product was being deployed into three separate business units, despite the companies being in three different but similar industries. (Two were involved in vehicle and spare parts sales and distribution.)
  
• The consulting firm advised AHG to undertake the three separate implementation projects simultaneously, the transport businesses being one of them. This was, in my humble opinion, poor strategic advice. I believe this advice was driven by the amount of billing the consulting firm could generate rather than what was in the client’s best interests. Guess who supplied the project managers, change managers, and other advisors to each of the three projects?
  
  I would have taken a very different tack. My advice would have been to build a central implementation team and work with the vendor or partner to implement the product into one of the businesses. Use that implementation to build capability in your staff and then use that team to implement the product into the other two businesses, one at a time, using the vendor to provide support around industry-specific matters. Yes, this would have taken longer, but the business would have a significant self-sufficiency capability at the end of those projects. That’s priceless, and that lack of capability seems to have come back to bite Scott’s later down the track.
  
  
• A poor-performing software implementation partner was chosen. Now, this can happen in the best selection processes. It can be that those software partners, for various reasons ranging from outright lies to being a victim of circumstance or a loss of key people can simply fail to live up to expectations. 
  
• The software partner operated under a contracting model and used different functional consultants in the project who had not worked together before. These all had different levels of experience – both in the industry (many had no idea about the transport industry) and with the product (one finance consultant had not used AX before); and they all worked under an implementation model with which they had no experience. It was fairly clear when I joined the project that little due diligence had been undertaken on the team working on the project.
  
• Scott’s Transport was at odds over process, the software’s functionality and capability with one of the other transport brands owned by the group. As is often the case when M&A activity occurs, there are conflicting ways of operating. As such, there were hotly contested debates over who was right and wrong in relation to process and configuration decisions. The political climate significantly impacted this business’s ability to provide the software partner guidance on how they wanted the business to operate. Watch my video where I discuss the role of politics here:
  
  The Role of Politics
  
  A business implementing an ERP must be on one page about what they want. A vendor can advise how they have implemented the product elsewhere, but in the end, the client has to know what they want and be able to change processes to work with the software. This is one of THE biggest reasons why IT projects of this nature fail, and in Scott’s Transport’s case, gets the blame for the business going into administration.
  
  
• The transport management capability was not native to the product and was delivered by an ISV (Independent Software Vendor) based in Europe. Their product (Module), in this instance CapCargo, was an add-on that added functionality to the core application. Using an ISV to fill a functional gap ensures all programming protocols and processes are standardised and aligned with the rest of the product and leverages the same database. In this instance, the software implementation partner didn’t have the necessary experience in this ISV to understand its capability effectively, and the level of interaction with the owners of CapCargo was unclear and ineffective. The support partner was implementing the product, in which they had the capability, but support for this specific ISV is difficult to find. When working with the company that wrote the module, Europe is not the most manageable time zone to coordinate with or work in from Australia. So this presented them with more issues.

My involvement with that business ended at this point.

The decision to upgrade from the on-premise version of AX 2012 to the cloud version of MS Dynamics Finance & Supply Chain would have been made because Microsoft would be pressing all companies to upgrade from a product that was no longer supported. Undoubtedly, the company’s risk committee would have been uncomfortable operating with a product that was “unsupported” and made what they would have felt was a sound decision.

This is an often-heard refrain from software vendors and the reason driving many upgrades currently being undertaken.

My observations on the remainder of the article and the upgrade project are made without being close to the project but based on my experience with many similar projects.

• From the stories I have heard, Scott’s did not learn their lesson about understanding a software vendor’s capability. The business had progressed through several different Microsoft software partners, none of whom were expert in CapCargo and many suggesting and developing modifications – something the project governance failed to control.
  
• The decision by Scott’s to go live with the upgrade during a busy period is a classic sign that the project was off the rails, running late and costing more than was expected. And so, the decision to go live was blindly made without considering the risks. There would have been a feeling in the business, “We have spent enough on this; it has taken too long; this must stop – go live”. There would have been an unwillingness to invest any more – because there is no doubt delaying would have cost more money, and, in hindsight, the company did not have the money.
  
• The article discusses the bottlenecks of pallets and trucks caused by the flawed go-live. This seems a little overblown because the company had been using this product, in an earlier version, for several years. There is very little difference in the shift from an on-premise version to a cloud version operationally. The system’s processes were not foreign to them. I suspect something else was at play here, and I think it was once again related to poor vendor selection and approving unnecessary modifications.
  
• The article also talks about a lack of governance over the project. I think they suffered significantly from political issues back in the original implementation. I would suspect those challenges didn’t magically go away. Governance can only go so far. If the political environment is volatile, then strong executive management is required – often this is not always in place.
  
• The article also indicates, “there was an agreement the CabCargo (sic – CapCargo) IT upgrade was required, but the timing was off, and it was poorly executed.” 
  
• As I mentioned before, I would disagree the upgrade was “required”. In my opinion, there is fault here to be laid at the feet of the risk committee of the board. While Microsoft was no longer supporting the on-premises version of the product Scott’s was still operating, and I believe too much emphasis is placed on the importance of the system being “supported”. My question to businesses running old versions is this: “When was the last time you actually needed Microsoft to fix something in that system for you? When was the last time something ‘broke’?” The answers are generally never. These systems can operate for a good period past the support term. Yes, eventually, the underlying platform and operating systems create issues with security and compatibility with other systems. But that’s not an immediate issue needing quick resolution.
   
  This business could have kept running on the same system for a period of time until the impacts of COVID and some of the other issues mentioned in the article were remedied. 
   

The key takeaway here is around human failures, not an IT upgrade failure. I see this all the time. Unfortunately, it is usually when people don’t take my advice. 

If you have an IT matter to discuss, schedule a time for a virtual coffee and I’ll give you unfiltered and unbiased independent advice. 

Let’s make sure you are not left out in the cold like Scott’s Transport was.

© David Ogilvie