There are many problems that result from shipping too soon. You could permanently damage operator buy-in with a poor initial showing. Modifications to the machine might be poorly documented. It could become tremendously expensive and take a very long time to fix problems in a live production environment. Fundamental problems, such as fault recovery, poor system diagnostics, and general operation annoyances might never be properly addressed. It’s more likely than not that there will be many band-aids on your machine before you’re done.
When a machine leaves your factory, most of the support system stays behind. Remote support might be an option for you, but think about the efficiencies that simply are lost.
In many cases, once a machine lands on the customer’s floor, it goes into production right away. Trying to eliminate bugs in this situation is like trying to finish an airplane’s assembly in the air. This is especially true for machines that are part of a larger overall line, such as packaging equipment and printing machinery. Your controls engineer might wait eight hours to get a 30-minute window of opportunity to implement important changes. Beyond the obvious costs, this is not where your development engineers want to be or should be.
If you’re building multiple machines for the same site, shipping the first one before all of the major bugs are worked out—and while the production on the successive machines continues—could cause tremendous problems. Ask yourself if the design changes you make in the field will be replicated on the subsequent machines, or will your customer end up with several machines that are mostly, but not entirely, alike.
We can’t avoid all of Murphy’s Laws, but there are some things that can minimize the risk of shipping a partially tested machine. Remember those project management fundamentals: set realistic schedules with contingency plans; update progress on a very regular basis; and do the hard things first. Commit to clearly defined runoff criteria, including, most importantly from my experience, robust fault handling and recovery.
There are other, maybe not-so-obvious ways to stay on schedule. That new controller you found might be a little less expensive or have some new features. However, it’s important to conduct a true analysis of the risk of putting unproven hardware into a new system. Create a modular design where each subsystem can be fully tested independently.
Your customer also should be careful not to go too far with the penalty clauses in the purchase agreement. The worst application of this is the “balloon penalty” where the supplier forfeits the entire penalty once the deadline is missed, e.g., 10% penalty at four weeks late. At this point the supplier has no incentive to finish the job in a timely manor. The more common “progressive fine” that increases the penalty for each day late will encourage the builder to “stop the bleeding,” but often results in shortcuts and shoddy workmanship. If the buyer is insistent on penalty clauses, a better approach would be to tie incentives to specific milestones within the project, such as design approval or receipt of all purchased material. This gives the supplier incentives in smaller, manageable amounts and facilitates regular reviews of the progress.
There is a balance between good enough and perfection, and many times the final machine development does have to take place on your customer’s production floor. Just keep in mind that for a system that might be in place for a decade or more, a delayed implementation is more likely to be forgotten than a poor implementation.
| About the Author |
