This case study does not have a happy ending. It is a story of why this project failed, and what could have been done to prevent it. The names of all involved have been omitted to protect both the innocent and the guilty.
What was the aim of the project?
This was a project for a large manufacturing division of a JSE-listed company. This factory has multiple manufacturing lines, each line has numerous machines, and each machine requires specialised settings and maintenance. The initial machines of each line also have unique moulds for each product, where a set of moulds is between 28 and 56 pieces. These also need to be maintained and eventually re-machined or replaced.
The aim was to implement a piece of software that would assist the maintenance department to manage, maintain, and repair their very expensive and expansive manufacturing equipment.
This software would integrate into the company’s ERP (Enterprise Resource Planning) system, and manage the equipment and moulds throughout the assets’ life cycle. When dealing with asset management, software like this is invaluable for a number of reasons:
- You know where your assets are, when last they were used, and when last they were serviced.
- You can manage your MRO (Maintenance, Repair and Operations) stock, and order required parts in time for servicing.
- You can plan activities months in advance, taking into account manufacturing plans, availability and lead times of MRO stock.
- You are able to enhance, expand, and track assets throughout their life cycles.
- You can make data-driven decisions, such as when to replace an asset.
So why did it fail?
How can I say this project was a failure? Just before COVID, the project had been going for three years already, and preventative maintenance planning was still being done on Excel. In other words, it had become a Zombie Project.
The first problem: The people NOT involved
During the entire run of the project, only two people were involved in it: the maintenance-planning manager and the project manager assigned by the software vendor. Even though the project management office was available, the project owner (the maintenance-planning manager) elected not to use their services, as he hoped having the assigned project manager would be enough.
Unfortunately, the project manager did not know the business well enough to include the correct stakeholders. This meant that stakeholders, and thus also project resources, were not involved from the beginning and did not buy into the project. For more on this, read this article.
The second problem: The wrong approach
As mentioned, in such as large manufacturing environment, there is a large amount of data that needed to be captured, and only a phased approach would work. The alternative, a big bang approach – where all the data is loaded, and then the software goes live – is what was decided on.
Had they taken a phased, more agile approach, i.e. pick one manufacturing line, and start loading data specifically for a product that is manufactured often on that line, it would have shown quick wins, and the software would be rolled out one bit at a time, seeing returns on the investment much sooner. It would also mean that learnings made during the initial phases could be applied in subsequent phases, thus speeding up the implementation as each iteration goes faster and faster.
The third mistake: The wrong KPIs
As they chose to go big bang, the KPI they elected was to check progress as a percentage of total master data that needed to be loaded onto the new system. While the project showed a 4 to 5% progress each month (which implies it would take 100 weeks to load all the data), during those 100 weeks, no benefits were realised. While this KPI is good, as per this article, it was not an effective KPI – also see this article.
The better KPI would have been cost vs benefits realised. Had they chosen to phase the project by line and manufacturing frequency, there would be slower initial progress (perhaps not 1% a week) but when the first set of data was loaded, there would be a benefit realised immediately, with increasing benefits as more products are loaded, and eventually each line.
How could this have been prevented?
Had the project owner decided to involve the project management office, or an experienced project manager, a methodical repeatable approach to project governance would have been implemented. This would have ensured that the right stakeholders were included from the start, including the various maintenance teams, IT, and the finance team. It would have also ensured that a more agile approach was chosen. Finally, the goal – and hence the correct KPI – would have been front and centre and, instead of having a lame duck after three years, they would have had a functioning piece of software.
For more information and downloadable resources to prevent your next project from failing, go here.