10 Things About Production Scheduling Automation | BBA
top of page
Search

10 things no vendor will tell you about why most production scheduling automation projects fail.

HINT: do NOT fire your production scheduler!



Here are 10 things we have learned over the years that will ensure your production scheduling automation project will fail. No vendor will tell you about them because they want your business. So, why are we telling you? Because we want you to succeed – whether you hire BBA or someone else.


1. You expect the new system to replace your scheduler.


In a recent client call, the IT lead on the project mentioned that the system they are looking for should “eventually be ‘autonomous’ and should not require a user to run it. Furthermore, a new optimization should be triggered in real time, either at the start of the day or when a significant disruption occurs on the plant floor.” . In this particular case, the scheduler in question was present on the call, and I knew it. So. I quickly replied that, “while this is a great aspiration, reality is different. The solution is designed to enable the user – i.e., Rose, the scheduler – to work more efficiently, and focus on value-added tasks as opposed to data input and error checking.” I could feel the relief in Rose’s voice when she thanked me for saying that, and she quickly became our best advocate and champion within the client’s team.


Vendors will typically tell you what you want to hear. They are often unwilling to contradict you, especially if you are one of the main stakeholders, or a high-level executive involved in the project. We, at BBA, know that during the implementation of any project – especially a scheduling optimization project – we must rely on key client personnel. One such person is the scheduler, who is usually very experienced in her role, knows many of the critical details about the production process, and will always be willing to criticize and provide valuable insights and feedback during the implementation process.


So don’t expect the new system to be a replacement for your scheduler. However, aside from facilitating the scheduler’s job, you should expect the system to make it easier for another, less experienced user – say, during the main scheduler’s well deserved vacation time – to be able to obtain high-quality schedules and keep the operation running smoothly.


2. You want to optimize your production schedules because everyone else is doing it.


This one, although it should be obvious, kills many projects. You go to a plant managers’ meeting or trade show, and you hear a vendor presentation about all the hype behind “new and improved” scheduling software that has solved every problem for some organization, and now it can solve yours. Beware: the fact that the other organization was able to derive value from a new scheduling system does not necessarily mean you will.


Before you go out there and purchase that “silver bullet”, you should first assess your own situation. Will an off-the-shelf scheduling tool work for you? Or is your operation so much more complex that it will require a custom solution? What additional value can you derive from creating better production schedules? Do you produce multiple SKUs? Are there costly setups required when changing production from one SKU to another? Do multiple SKUs share the same production equipment? The same tanks and other storage facilities? Do you believe you are running your plant less efficiently than you could? Would increased efficiency translate into considerably higher margins for your products?


The fact that others are optimizing their production schedules does not mean that you should. You should only invest in new production scheduling technology if doing so can lead to a positive return on the required investment.


3. You don't have sufficient buy-in from the top.


Another obvious one. If you have not secured buy-in from your higher-ups, the project is doomed from the start. Work on creating a compelling business case for the project. Not only will this help you “sell” the project to upper management, but it will help you determine the value proposition of a new, improved production scheduling solution.


4. You demand a fixed price contract.


Fixed price contracts are great when there is an off-the-shelf solution that satisfies your needs, or when there is a limited project scope with clear requirements. For longer-term, more complex projects, however, the requirements are usually fuzzier, and fixed price contracts can actually work against the desired outcome of a high-quality solution that will bring sustainable value to your organization.


For one, fixed price contracts make it difficult to change the requirements. Typically, the contract will include a mechanism for scope changes that requires written mutual agreement. The service provider will have to “price” the scope change and make a proposal to the client. The client will then have the burden of determining whether the scope change justifies a budget increase (in which case the project owner will most likely have to obtain the required approvals…), or whether there is a part of the original scope that can be “sacrificed” in order to preserve the original budget and, thus, avoid having the get new approvals.


To avoid this often cumbersome and costly process, service providers will seek ways to include certain scope changes within the approved budget, which leads to what is commonly known as “scope creep”. Unfortunately, scope creep usually results in low quality work because the service provider will inevitably want to utilize less expensive (read: less experienced, less talented) resources to complete the additional work. This, in turn, will strain the relationship between client and service provider, ultimately resulting in the potential failure of the project.


Time and materials (T&M) contracts are becoming more common in consulting and software development engagements and, while they do come with inherent risks, they also present undeniable benefits, both to you, the client, as well as to the service provider.

Under a T&M contract, the client will pay the provider an hourly rate for time spent on the project plus any costs of materials. The advantage of the T&M model is the added flexibility and the opportunity to adjust requirements, shift directions, when necessary, replace features, and involve users in the process. This last item is of utmost importance: involving the intended users. Under a T&M contract, it is more straight-forward to perform user acceptance testing (UAT) of the solution, obtain feedback, and adjust work scope accordingly.


Of course, T&M contracts will require a higher level of involvement and oversight from the client to ensure that the work is progressing as expected, that scope changes are well documented, and that new commitments and project milestones are being met. It can be argued that this additional level of involvement, while resulting in an internal cost, is a positive tradeoff when you consider the outcome: a better-informed client with more engaged users.


In an ideal situation, the client can ask the service provider to prepare a proposal that uses a hybrid approach: an estimated price cap (usually high enough to accommodate dynamically changing requirements: kind of a worst-case cost scenario), with an engagement model based on a T&M approach, where scope changes can be incorporated without the need to obtain new budget approvals.


5. You want to boil the ocean.


When you first embark on a production scheduling implementation, it is a good idea to think big. Work on the design of what – to you – would be the “ideal” solution. Start with a comprehensive assessment of your situation and identify your business objectives and any constraints that apply to your operation. Think big picture and don’t limit yourself. Make sure you do a thorough job of gathering requirements from a broad set of stakeholders whose roles may be affected, in any way, by the new solution. For example, if the new solution will be expected to automatically generate purchase orders for materials required during production, then make sure you include the purchasing department in the project.


However, once you start down the road of implementation, don’t try to boil the ocean. In other words, don’t try to achieve the ideal solution in a single step. Assuming that your operation is complex enough to require a custom solution, getting to that ideal solution will most likely entail a rather long process, fraught with multiple scope changes and ideas for enhanced features along the way. Trying to get to that ideal solution too quickly and inflexibly will probably result in failure. Rather, plan your implementation in multiple phases and start with a Pilot phase.


A Pilot phase is critical to success. Identify an implementation scope for the Pilot phase that will provide the operation with 80% of the expected benefits but includes only 20% of the planned functionality of the ideal solution. The Pilot, when carefully designed, should result in a prototype that includes the key technical aspects of the solution, and can get you most of the expected benefits: better production schedules, reduced costs, reduced wasted resources, and improved business indicators (the “must-haves” of the solution).


The Pilot will likely not include additional capabilities, such as automated data input and output, or fully integrated ERP or MES systems; therefore, real-time tracking of jobs, or rapid re-optimization of the schedule (the “nice-to-haves” of the solution) may not be possible at this stage.


Starting with a Pilot phase will provide other added benefits, as well. It allows your users to become familiar with the prototype and to identify additional features and enhancements to include in the design, to be implemented during subsequent phases of the project.


6. You prefer to skip the pilot.


For the reasons mentioned in #5 above, don’t – I repeat – DO NOT skip the pilot. Consider the pilot as paying for an option on your investment. You pay a lower price for the chance to prove the concept you are implementing, with the added benefit that you will get a working prototype when the pilot is complete.


7. You don't do enough testing.


To ensure that the solution will work for you under many different circumstances, you need to conduct thorough testing. This includes setting up several test sets, where you use historical data to compare the performance of the new solution against the way you approached things in the past. It must also include a user acceptance testing period, where the user(s) of the tool test it “as if” they were using it in a real production environment, alongside their current scheduling system, to make sure any unforeseen circumstances can be handled by the new solution. You should also include “stress tests”, where the solution is tested under unusual and difficult circumstances, whether real or made-up; for instance, a machine going down for a long period, or one or two key plant operators being absent during a shift or two.


The purpose of thorough testing is multipronged. First, and obvious, is to make sure the solution works as expected under normal circumstances: that it optimizes the correct business metrics and does not violate any of the system constraints, while producing a quality schedule. For this reason, testing should be done continuously, even while the initial prototype is being built, and all the way through post-implementation.


Testing also involves less obvious goals, like training users, getting feedback from users, and making sure it handles unexpected or difficult situations correctly, or that the users know how to use the solution correctly under those circumstances.


8. You forget about the follow through.


One of the reasons many projects fail is that people consider them “done” too soon. After implementation, many stakeholders and managers will turn their focus elsewhere. However, the implementation of a new production scheduling solution does not really end at implementation. Things may change in your operation and, depending on the complexity, some changes may affect the solution and require adjustments that were unforeseen during development.


Make sure you put in place a system that will monitor and assess the performance of the solution well after its initial deployment and into the future. Make sure this performance is communicated on a regular basis to the plant management as well as the plant operators to preserve the level of credibility in the solution. The solution may require changes in the way things are done, which may cause resistance from plant personnel who “had been doing it their way for many years.” Never underestimate the need to manage these changes, by explaining the benefits of the new tool and objectively showing these benefits using the right metrics.


While it may be uncomfortable for someone to change the way they have been doing things, it is easier to convince them to change if they can “see” the benefits for the organization. Even better would be to relate those organizational benefits to their own personal situation – through alignment of incentives.


9. You expect an easy button.


Most custom solutions will not come with an “easy button.” If your operation is complex enough that an off-the-shelf tool is not enough, chances are that a production scheduling solution will require a user that will monitor its output to ensure the schedules suggested by the solution can be readily implemented.


This goes back to item #1 above. Don’t expect the solution to replace your scheduler. Expect the solution to add value to your scheduler’s job by making them more efficient and effective.


10. You don't have your best people on the project.


This one is obvious, too. Put your best people on the project. That does not mean you should ask your HR manager for a list of the employees with the highest performance rating. No, this means getting the people whose roles and responsibilities will likely be impacted by the new solution, involved in the project from the start.


Make sure the opinions and insights of those stakeholders are well documented and considered when gathering the requirements and during the design phases of the project, and that they get to test – or, at least, see a demo – of the solution many times along the way.


In our experience, these are the Top 10 reasons these types of projects will fail. Like with any important human endeavor, “the proof will be in the pudding…” or “the devil will be in the details…” (you get the idea.) However, if you are managing your project effectively, avoiding these 10 pitfalls will greatly increase your chances of a successful outcome. On the other hand, failing to address any one of these will essentially guarantee that your project will fail. Don’t say we didn’t warn you… (… most vendors won’t).

bottom of page