When Big Things Go Wrong

I was watching a Netflix show recently called, “When Big Things Go Wrong”. It is essentially a documentary about engineering failures like bridges or building collapses. They investigate a number of different catastrophes and build the story around identifying what went wrong and outlining any lessons learnt. It is similar to the aircraft investigations program that fundamentally is designed to make everyone feel safer flying because, as an industry, aviation has learnt so much after each crash. I based my first book on a similar principle, that many digital transformations in business are not dissimilar. There are similar common issues and lessons learnt. The key contributing factors outlined in the Netflix series are:

• Flawed design
• Missed signals
• Cutting costs

In the digital transformation space and ERP more specifically, those contributing factors relate to the following.

Flawed design can occur when:

• You have people working on your project in your design phase that will not be involved in the implementation. Their level of concern can be less than stellar and they have no vested interest in getting it right as it will be someone else’s problem when the implementation comes along.
• You have inexperienced consultants from your software vendor who have poor knowledge of the software and are limited in their delivery experience. They will often provide you with the design or configuration advice based solely on how they configured the software last time they worked on a project, rather than advising on what will make the best use of the system’s capability for your business. They can often be different. Just because one particular configuration worked in one business does not necessarily equate to it working in yours.
• You have inexperienced people from your organisation working with the software vendor’s consultants. If you don’t have those who know the business the best they may not be presenting the full picture to the software vendor’s consultants.

Missed signals can occur when:

• Delivery dates start to slip on a more regular basis. Often the relationship status amongst project team members is such that the level of accountability required is not called upon until it is too late. That is often because executives use the wrong management tool or technique on these projects. They rarely make the distinction between a project team and a committee for example. A key mistake. Watch my video on this topic below. 
• The quality of work is not up to the standard expected.
• The level of attention is not at a level required to ensure success.
• There are lots of small issues that never get resolved. ERP and digital transformation projects fail because they suffer the “death by a thousand cuts” as outlined above and not one big failure. Miss the signals and overlook corrections and then big things can fail.

Cutting Costs are impactful when:

• They are cut by purely accounting or finance-driven decisions. A business incurs a cost for a reason and before you indiscriminately cut that cost, one needs to understand what the unexpected consequences of removing that cost will have.

Take an airline, for example, they buy components for jet engines. A number of those components are manufactured and sold by numerous companies. They are not necessarily tied to the manufacturer of the engine for parts like fan blades. Just as you and I are not committed to the dealer we buy our car from. We have the choice to get it serviced and purchase parts for it from anywhere we choose and on whatever maintenance schedule we choose.

Many of those purchasing decisions are purely cost driven. The TV program Air Crash Investigations has highlighted many times where maintenance schedules have been pushed to or past their limits. Where inferior quality parts are used only to fail at critical moments. Our ERP and digital transformation projects are no different.

Many executives make cost-cutting decisions in good faith expecting the result not to be impacted very much. In the ERP space, for example, costs are seemingly cut by not committing a project team full-time to undertake the work. They feel that by having people committed part-time they avoid the additional cost of backfilling those roles with others. The reality is, the quickest and most cost effective way to undertake an ERP implementation is to have a fully committed project team. (Bearing  in mind my comment above on teams vs committees).

I have clients who have made the decision to utilise a part-time team only to find:

• The project work is always subrogated to business as usual demands, meaning it doesn’t get completed in time for the schedule or in as good a quality as it needs to be completed.
• The people involved get burned out having to operate two demanding schedules of work.
• It is a proven neurological fact that task switching is both demanding on one’s brain and slows productivity. Those involved on a part-time basis are task switching all the time.
• The quality of thought applied to a situation, whether that be the solution design, the quality and thoroughness of testing and other project tasks, is not as good as if they were fully committed.

© David Ogilvie