The Harry Potter Problem: Define the Why to Succeed With Your Machine Learning Project

You might have noticed a comment was made on the first article in this series: I didn’t mention the ‘why’ as a KSF in bringing home a machine learning project. And it’s true, forgetting the why is a serious problem. As the commenter noted: Unless there's a why and a businessperson involved, all you've got is a handicapped specialty group who have been given tools, but not told what to do with them.

So here’s my amended list of KSFs for a machine learning project:

1. Enough good quality data
2. A data specialist, to learn from the data
3. A process specialist, someone who knows how the process works
4. Choose your case carefully
5. Know the why and do not forget it

The Why is the Business Reason

The why is the business reason for the project. It’s rarely as exciting or motivating as the technology involved. But it pays the bills.

There are all kinds of ways to forget the why, or to define it poorly. The most common may be that a project’s goal goes something like: Use New Technology XYZ (sort of magically) To Make Things Better.

Such an approach leads straight to failure. The success of any machine learning project starts with defining why you’re doing it. Put another way, these are not toys for co-op students. In fact, they’re not even toys for expert IT coding technologists; even with the help of these people, many businesses tried and failed, for lack of a why.   

At Factora, we use what we call a B-M-T model: Business-Manufacturing-Technology. Experts and input from all three must be part of any kind of engagement; success is only possible through their alignment.

More Ways to Fail

Let’s say you’re starting a machine learning project and you have defined the why. Maybe it has something to do with predictive maintenance, or soft sensors, or predicting process issues.

Side projects: The next way to trip up is to define a machine learning project as a side project. Say:

• You’ve invested $25K in a proof of concept
• If the first case is successful, there are many other instances of similar situations in the plant or in other plants in your company.
• It looks like there could be $1 million dollars per year in business value
• Full-blown implementation would be around $250K. 

If so, why is this being executed as a side project? With juniors or interns, with the lack of an official stamp, and without the executive governance that earns it the resources it needs to succeed?

Perfection is the goal

The next big error is to define perfection (intentionally, or by default) as the goal. Let’s go back to that project where the proof of concept indicated a potential $1 million yearly payoff for successful predictions.

Now you’ve developed a process in the proof of concept that can predict this issue 50% of the time (saving you $500,000 over the year). It’s now as good as you can get it. And it’s no failure!

True, you’re only predicting half of the instances. But before you did this project, you were catching none. Your payback is six months.  Following that, you can continue on the journey. If you can now predict only 50% of the issues, you’re probably missing some data which would require some additional sensors.

Yet the example above was flatly refused by IT in a large corporation.  Their reason? “It’s not predicting 100% of the time, it’s missing half of the instances.” Clearly this was a cup-half-empty group, without an eye on the why.

Raise Your Eyes from the Technology and the Machines

Defining the why means focusing on the business benefit, raising your eyes from the technology and the machines. Many of the failures of 20 years ago in artificial intelligence, advanced process control and neural nets stemmed directly from forgetting the why — being swayed by the tempting Harry Potter promises of what new technology could offer.

How, What and Why

So manufacturing is the how, the technology is the what, and the business is the why in a machine learning project.

As an example, the what could be what version of software we’re using or the product. Totally irrelevant to the business value, as is the supplier who made the software, or the algorithms involved. Who cares, as long as it solves the problem?

Here’s another example I was involved in. Yet another promising machine learning project was refused because the site data specialist wanted to understand how the artificial intelligence algorithms worked and the supplier did not want to answer his request, for secrecy and competitive reasons. But when it comes to plant operations and saving money, there is only one question: Does it work continuously and reliably — or not?

The data specialist I mentioned was not alone. Machine learning and neural networks originally met with considerable resistance because they’re a black box, where the algorithm used can never be known (not to mention that their owners are not inclined to reveal even when they can; there may be corporate secrets involved in how an algorithm works).

So, while the data scientists and process engineers I mentioned in the first article are required, they don’t have the right profiles to drive these types of fundamental issues, the questions about the why.

The One Harry Potter Trick That Does Work

Have you noticed that Harry Potter and other wizards often look upward when they use their wands? It’s a good idea — the looking upward that is, not the wand-work. Too often, in projects that use exciting new technology, we’re drawn ever downward, into finer details, fancy coding footwork, and nuances.

But the way out … is up.

Look up, and away from the details, away from the specific nature of what you (as an IT professional, or process engineer, or data scientist) actually do.

Yes, the magical components are exciting, and seductive. But keep your eye on the prize. Does your proposed solution address the defined business problem? Or not?

Charles A. Horth is the CEO of Factora, a company of manufacturing consultants who use software to help factories achieve their full potential by raising the visibility of key information on the shop floor so that plant management, employees and company leadership can run more efficient manufacturing systems.