The Project Failed The Project Manager Got Fired
Why I don’t waterfall long projects anymore.
Looking back, I really don’t know how this project got funded.
The Facility:
Food & Beverage company with 8 facilties across the US.
The Project:
I walked into a Manufacturing Execution System Project most of the way through. We were instituting OEE (Overall Equipment Effectiveness), SPC (Statistical Process Control), Track and Trace, Recipe/Batch, and scheduling.
Setting the Stage:
We were two years into a project that should have taken a lot less time.
The PM had been on a power trip the whole time. The project was substantially from his brain. No one had talked to the people on the plant floor.
Let me make this clear- I would completely have the come to Jesus talk with everyone at this point. In fact if I walk into a project that is going this sideways, it’s either how are we going to get this on track, or just stay away.
The Problem:
Honestly, there were so many problems that it would be hard to pinpoint one.
– Company didn’t have someone experienced looking out for their best interests.
– Organizational issues galore.
– Terrible Scope that kept changing.
– Groups that did not understand the problems or realistic solutions.
– TOOK TOO LONG.
– One Project Manager had all the power.
– Bad System Integrator.
After all this the project rolls out and the scheduler, who typically does this on pencil and paper refuses to use the system.
Ideally the system with its rules would make her life a lot easier. She refused. No one forced the issue.
Thus no data into the system turned this project into an usable system.
The Results:
Scheduler refuses to change.
Project Manager gets fired.
$1 Million worth of system gets mothballed.
2 years worth of work at a facility down the drain.
No scalability with the solution.
Lessons Learned:
This is one of those projects that I came into at the end and eyes wide open know that it was going to fail.
I am more than happy to have the hard conversations now and regularly do. There are certainly more projects that I walk away from, but would rather walk away than spend some of my limited time focusing on these issues.
I now do a lot of roadmapping, discovery, and building functional requirements that will do what the end user needs. Change orders don’t help anyone. I don’t run a business based on needing change orders to make profit.
Some organizations are ready to change others are not. If any organization is not ready to go through the pain of change, I’m not even going to consider working with them in their current state.
Long waterfall projects don’t work when dealing with organizations change and automation. It’s too much all or nothing pressure. We need to find ways to gather buy-in and then slowly change. A phased approach showing value and benefit to the people on the floor is important for everyone.
Check out more of my thoughts on this with The Ultimate Digital Transformation Quick Start Guide.
If you don’t spend time on the plant floor talking to the people who are going to use the systems you’re building, you’re doomed for failure.
