I spotted this discussion, Why Industrial IT Projects Fail, on a LinkedIn group. Franz Gruber, Founder and Chairman, of Forcam “Driving OEE for the Manufacturing Industry”, posted this note.
My first Industrial IT project was in 1978. Many of his points hit my awareness way back then. Then I was involved in many automation projects over a period of about 15 years during the 80s and 90s. Once again, many of his points raised their ugly heads.
I bet that many of you have your stories, too.
But let’s look at Gruber’s comprehensive list just as a reminder of the many things to watch.
First, he lays out the problem:
- 17% of large IT projects fail so badly they threaten the very existence of the company (McKinley & Company 2012)
- IT Projects run 45% over budget, 7% over time, and deliver 50% less than predicted. (McKinley & Company 2012)
- 75% of project participants lack confidence that the project will succeed (Geneca 2011)
- 78% of participants report “Business is usually or always out of sync with the project requirements
He then provides two steps with supporting points.
First, can you meet the timeline budget, and requirements of your project?
- Define the scope and requirements of your project across all levels of users intended to use and benefit from the project. This can be achieved through close collaboration with a vendor who takes the time to understand your process, and in collaboration with all levels of users defines the requirements, and helps to define the corporate roadmap.
- Choose a vendor who will work with you to define your process and requirements of your process. Do not let a vendor define the software solution without first understanding your process, process changes are a business solution and not a software decision, this means the solution should fit your process and not try to make your process fit the solution.
- A cross functional investigation should ensure that the project will meet the requirements of management, supervision, IT, and shop floor environments, the more buy in you get in the requirements phase of the project, the more likely you will meet deliverable expectations, and the more support you will get as you are developing and deploying the solution.
- Ensure your contingencies are covered- make sure you and the solution vendor understand the requirements and they budget is established with full understanding of the project. This may mean a small investment in the beginning of the project to define the requirements, but the risk mitigation is well worth the investment.
- Understand the ROI and present it accurately. Often the fear of ROI requirements drive the inflating of expectations, if the project is truly worth the investment, the ROI should be plain and easily recognizable by decision makers within the organization.
Second Step: Select Current technology that is supportable.
- Technology is moving forward a light speed, upgrades and service fees are a killer of budgets, if you select a solution which is technologically obsolete in a matter of months, and you will be forced to make more project investment before the ROI has happened.
- Outdated technology makes it harder for acceptance on the plant floor, many of these “Non-IT” personnel are very technology savvy with personal computers and smart phones advancing at break neck speeds.
- Current technology also means more support options. Young and hungry IT professionals are coming into the market every day, these people come at a significantly lower cost than your seasoned war horses.
- Define your project plan – define a realistic and safe project plan for deployment of your solution, trying to present a faster timeline may seem like a good idea when you are getting the budget, but if you do not meet the timeline all benefits from your sales process will be lost in a lock of performance at delivery time, or even worse taking shortcuts to try to meet an unrealistic timeline you established in the beginning of the project.
Here is my comment on the post. Visit the site and add yours. Or, reply to me with your experiences.
Right there in the first point is a huge problem to overcome–silos. Someone is assigned a project by their manager. (In my case, my VP wanted to extend his “empire”.) So, it’s a one-department solution for the entire company.
That does not work. As they say, “Been there, done that, have the T-shirt.”
As Dave says, never automate a bad process. Get your kaizen teams or whatever your process and rationalize and improve operations. Software can provide information for teams to use to improve processes. Software alone will not improve processes.
Any application to complex to use will not be used!