Working with Industry: From the Laboratory to the Field and Back

If you work as an academic in science and engineering, you are going to be surrounded by colleagues who work with robots or microchips, materials or mice – objects that fit in a laboratory where you can run real experiments and test hypotheses, which allow you to write papers and obtain patents.

In operations research (O.R.), we have this habit of working on problems that do not fit in a lab: optimizing trucking companies, manufacturing systems, power grids, hospitals or a military operation (which was the problem that originally motivated George Dantzig and his development of the simplex algorithm).

Instead, we followed the style of the early pioneers in the 1950s, who were primarily mathematicians, such as Dantzig and Bellman, in which we would create mathematical models of these physical systems and then develop algorithms and prove theorems to show that the solution is optimal! As computers evolved, we started to create computer models, primarily with made-up data, but increasingly with data from the field. The problem was we would collect the data needed for our model without recognizing that the model may be a poor representation of an actual problem. Even today, empirical testing of models by academics remains a major weakness of our field.

In this article, I am going to discuss a number of issues that need to be addressed when going down the path of working with industry, from my experience.

Why Work with Industry?

There are several reasons to work with industry. In my experience, the most important were:

• Money – Let’s face it: We need funding to pay for graduate students, summer salaries, computers and travel. This is particularly true for those of us working in engineering schools. Over my career, industry support constituted more than $40 million of my $60+ million in research funding (in 2025 dollars).
• New problems – Industry is a great source for new research challenges. Without the force of real problems, faculty often go down the path of tweaking the results of published research (there is quite a bit of this).
• Data – Government agencies are a source of funding, but they don’t have data. Companies have data, but you have to make sure they are willing to share it. I found that trucking companies and railroads were quite willing to share data, whereas manufacturers tended to be possessive of anything related to their supply chains.
• New theoretical questions – Real-world problems often create the need for new theory, as I found when I was pulled into the general area of making decisions over time under uncertainty.
• Field testing – Companies offer the opportunity to see if your research works in the field. The downside? Companies want to see your research work in the field, and they expect it to work the first time.

A major challenge facing faculty looking to work with industry is making sure that the problems being posed not only are interesting to the sponsoring company but also offer opportunities for publishable research. Identifying these bridges was perhaps the most important skill that I brought to the research.

Why Should Industry Work with You?

It is important to understand the different reasons that a company might have to work with a university. Some of these include:

• Prestige – Managers like to be able to say they are working with a university to solve their problem, just as companies might hire famous (and famously expensive) consulting firms.
• Access to faculty – By providing funding, companies are buying the ability to talk or meet with you (and possibly other faculty). The company may have an in-house technical team that needs help or managers looking for some expert advice or free consulting.
• Access to students – Funding research can be a way for companies to gain visibility with the students, making it easier to attract them for future employment. However, you have to think about whether your students might want to work for these companies. I did a lot of work with freight transportation companies, knowing full well that my students at Princeton University would not necessarily want to work there. I became very accustomed to doing projects with Industrial and Systems Engineering (ISyE) graduates of Georgia Tech.
• Deliverables – In my experience, deliverables came in two forms:
  1. Results of studies you might perform to help companies with their planning.
  2. Software that delivers new models and algorithms they can use to improve their business.

All of my work with industry initially focused on the development of models and algorithms, although I would periodically use my models to conduct studies.

What If They Want Software?

Throughout most of my career, companies wanted software. These requests fell into two categories:

1. Operational software for dispatching trucks in truckload trucking, planning operations for less-than-truckload carriers, dispatching locomotives and planning inventories for high-value spare parts.
2. Models for simulating complex operational problems for performing strategic planning exercises.

Without question, my most demanding projects involved writing software that was implemented in the field for planning operations, but be forewarned: These projects are hard and need to be staffed appropriately (see Figure 1). The biggest challenges of operational models were:

• Getting data into your model and dealing with data problems.
• Recognizing when your model is wrong and then fixing it.
• Designing and then refining your algorithms (which might mean starting from scratch if you realize your model is wrong).
• Working with people who are supposed to use the model.

It was sometimes hard to know whether the behavior of the model was a result of bad data or modeling errors. We developed a general-purpose tool called “Pilotview” (see Figure 1), which was critical for this purpose.

Digital Twins: An Opportunity for Academics

In my experience, from the perspective of an engineering school, universities are particularly well suited for developing “simulators” for performing a wide range of planning studies (called “digital twins”). Examples from my lab included models for a large truckload fleet and a fleet of business jets; an “optimizing simulator” based on approximate dynamic programming for locomotives; scheduling generators for the power grid; and an entire series of simulators for testing policies for energy storage devices. We would also develop simulators for designing, tuning and evaluating policies for a wide range of stochastic search problems, whether optimizing materials in a lab, testing drugs for a patient or evaluating bidding policies for e-commerce.

All of these “simulators” are actually stochastic optimization models that may be used for either of two classes of decisions:

1. Choosing static design parameters, such as the size of a fleet, location of warehouses, design of products and capacity of a manufacturing process.
2. Making decisions over time (planning inventories, dispatching trucks, testing drugs, pricing products), in which we have to search different classes of policies and perform tuning of any parameters (which are almost always present).

A true digital twin is a carefully calibrated simulator that has been designed with the close collaboration of the company, using validation metrics. A digital twin can be used as a test environment in which faculty can pretend they are actually running their models and algorithms in the field. To be credible, a serious effort should be invested to make the model as realistic as possible. This means not only capturing the physics of the problem but also modeling different forms of uncertainty. 

The Value of a Joint Research Partnership

The standard academic model is that professors come up with theory in the university and then apply it to industry. The problem is that “theory” (at least in the context of operations research) is typically done with a stylized model. 

There is no shortage of examples of academic research that did not survive the transition to the field, from simplified deterministic optimization models to most forms of stochastic optimization. However, all models are approximations, and the only way to evaluate and refine approximations is to try them. 

In 2006, I wrote a document titled “From the laboratory… to the field … and back” to capture the need for iterative learning. Some of this learning can be done with a simulator, as long as it is fairly accurate and captures the important characteristics of the problem. 

Iterative learning is of central importance, yet it is one that is relatively rare in O.R. Contrast this with the experience of physical scientists who are endlessly trying experiments in the lab. It is this process of trial and error that is the foundation of the sciences but often missing from operations research. It is much easier to sit in our offices and prove theorems and test algorithms on datasets without validating whether the results work in the field. 

But Is It Research?

There is a strong bias in the O.R. community that “research” is “theory” (or computational testing), while any work with a real operational problem is “consulting.” Academics want to test publishable new methodology, whereas companies actually prefer something that is simpler and more reliable. It is the responsibility of the academic researcher to identify problems in which the real application actually needs new methodology. 

I know several colleagues who do all industry projects on a consulting basis. This is fine if the project is well defined with a very high probability of success, but if this is true, then the work really is consulting. I understand the desire to supplement academic salaries, but this model will not work on complex problems that are high risk and require the trial and error of an academic research model.

In 2012, I landed a major grant with AFOSR (joint with Peter Frazier) to do optimal learning for materials science. Although Peter and I brought our traditional bias toward developing new methods, it quickly became clear that it did not matter to the materials scientists that we worked with (a requirement of the project) if our methodology was new; they just wanted something that worked … in real experiments … in the lab.

A number of fields (environmental engineering, public health, forms of biology) have strong traditions of field research. O.R. is a field that embraces many problem areas that do not fit in a laboratory. As a result, our community has adopted a style of research that prioritizes algorithms for simplified models rather than advances to the process of modeling. We run many simulations of stylized models, but we need simulators that have been subjected to a rigorous calibration process.

Staffing the Team

The standard model of a professor supervising a graduate student will not be able to take on serious software development projects. CASTLE Lab was started in 1990 with the hiring of a former Ph.D. student (Hugo Simao), followed a few years later by the addition of another professional programmer, also with a Ph.D. in operations research. Graduate students continued to do the kind of computational testing of algorithms that is familiar to the O.R. community, but the dedicated professional staff were an absolute requirement for the large-scale models that we were developing for industry. Postdocs also played an important role, but their activities tended to be more like the work of graduate students than that of the professional staff.

Ownership and Licensing

Software containing models and algorithms introduces issues that are not familiar to other areas of research, which can create problems when dealing with standard university research contracts.

Who owns the software? At Princeton University, I was able to work out an arrangement in which Princeton owned the software, even if it was developed for a single company. However, the company received a “nonexclusive, perpetual, royalty-free license” to use the code. Sound simple? It is not, and I had multiple colleagues from other universities who wondered how I pulled this off. In my case, it came down to a critical person in the grants office, John Ritter, who understood that the first goal of research is to help the faculty and students. I think he also realized that software of this type is simply not going to generate a significant stream of licensing fees compared with, for example, a license for a breakthrough cancer drug.

Closing Notes

The O.R. community needs to develop a richer tradition of field research if our field is to develop a true understanding of solving real problems. The tradition Dantzig started that emphasizes algorithms needs to be replaced with a focus on designing models.