How can you design better R&D tests?

As I have been around 35 years in the feed industry, I recognized that many trials were flawed due to some errors in test set-up. So I wrote a book last year (95 pages) on how to set up scientifically based trials in aquaculture.

One thing that I have found helpful is considering regular and precise documentation st this step. At the industry scale, the R&D projects starts with defining the aims, exploring the possibilities, reviewing the resources, and determining the quality standards. It's very important to have all this data documented and accessible to all the R&D team members. The study director may design the final process but surely the members' feedback and having the insights from quality team can be beneficial.

Decide on the R vs the D upfront. Are you exploring for the best path or are you paving the path you have already identified. R>d or r<D. Research finds new stones, Development polishes them to gems. They are related & overlapping activities which is why the outcome goal should be clear to define priorities & goal outcomes. Nothing is more demotivating then a successful search for a new raw stone being called a failure because the (unknown/unclear) goal was to polish the old stone to perfection.

Based on my own experience and looking on some examples around, it has to be clearly said, that often the objective(s) of started R&D work are not always set in SMART way (google "SMART criteria"). And it is not always because of lack of a competence, but often due to lack of the knowledge about the context of the objective(s) (voice of customer and real business needs, estimated resources, etc) and poor information exchange between all involved parties and colleagues. As a project progresses, more different sorts of information become avaliable (which would be greate to have before starting the project. Some projects might not be even started having necessary information in advance) and the earlier set objective(s) should be updated.

Standardised R and D test protocols are developed after years of research and any subsequent variations are a result of modifications introduced knowingly without proper considerations or unknowingly, to these procedures. Over time, the consistency of these tests can be only be ensured when people are trained competently.

All successful science is built upon reproducibility. Use and build upon methods and techniques which are proven reliable by many different users.

Remember always to use standardized work instructions for the test methods and clear definition on the expectations, is as important as defining the right method as to make crystal clear how a test can be passed or failed

Don't be afraid to jump in the lab and do some, (thoroughly documented) rough testing before starting a Design of Experiment. Understand the process bounds and what resolution you need when using Design of Experiment methodology. Extra exploration and planning at this stage is well worth it due to resource consumption of the study itself and analysis in comparison.

In my practice, I've found that development is a (x3) legged stool: hand calcs, numerics, and experiments. Show me one of those and you can get some money and confidence to show me more. Show me (x2) of (x3) and you're really unlikely to be wrong and you deserve real resources to prove out your idea. Show me all (x3) and you've mastered the subject and can easily explain, defend, and transition your concepts to the rest of the organization.

As you choose your methods, I think it is also important to consider the eventual end goal. For example, if you are testing an agent for eventual use in a human, has the method you have chosen ever been shown with another test agent to be translatable to humans. Just important to keep the end goal in mind.

This is a big part of us this a BIG R little D project where expensive time consuming measures are valuable for the information they provide, or Big D where the budget should focus on things like purity/quality control for example.

Be realistic about what you could achieve with the "available" resources you possess (not what you might attain at a later time), it is better to not start a project until all the resources are in place, telling a "half" story is not so good and unfortunately, sometimes you get one shot to tell the story.

It is one of the crucial part, while planning the resources - Test your assumptions by incorporating validation mechanisms to challenge and validate underlying hypotheses, promoting robust and reliable results.

the articulation of tasks is also essential. A diagram/schedule often shows that some things need to be finished before others start and it helps with scheduling and allocation of resources.

At an even higher level: plan. 1) Define the goals and objectives for the test. 2) Identify the responsible team and lead / owner. 3) Plan a high-level timeline and workflow. 4) Identify risks, propose preventions/mitigations. 5) Review progress and adjust as required. Even a small amount of planning will make a big difference between a failed and successful project.

Is "R&D test" the right title? I heard of lab test, soil test, quality test, etc. But "R&D test"? I am curious - Who uses this title?

De forma muy jocosa, yo siempre digo que toca saber escuchar el experimento. Que la idea o hipótesis preliminar no interfiera creando ruido que pueda interferir en el resultado obtenido.

I would call it R&D investigation, but test is also fine. It is a specific investigation of a certain issue. Test is more coming the the software development world. Although we can also call it a validation test in other area, too.

R/D is testing assumptions and using your new knowledge to chart previously uncharted paths! In R/D, we think up a new idea and propose it; there are implicit assumptions at that very moment. We approach R/D with an open mind to learn. We don't learn in an unguided manner, we learn guided by the organization's Mission/Vision, diving deeper into those areas that are core and leaving the other areas behind that are not part of the core Mission/Vision. Forget "fail fast". Anyone can fail quickly. Envision "learn with intent", disseminate that knowledge, solicit input from all parts of the organization (Engineering, Marketing, Sales, Finance, Operations, ...) to help put your knowledge into context and map out the next investigation.

Esto es una cuadro, en la tabla tienes todas las condiciones de contexto que explican la relevancia de la investigacion y todos los aspectos descriptivos de esta. Lo más correcto es asumir que todo es una suposición. A) el usuario en x situacion deseando Y. B) la razón por qué algo no sucede C) la solución es Z.

Every iteration will become an improvement only if the R&D tests are properly designed. Studying the variables that can influence the results and modifying them one by one becomes crucial. I have helped many R&D technicians that used to change two or three variables at the same time, losing completely the sense of the experiments. This may seem very obvious, but I have realised that is a common mistake in some R&D departments.

As a scientist, it is a well-established practice to conduct experiments multiple times to ensure the reliability and validity of the results. The key to perform replicates lies in maintaining a thorough documentation of the experimental steps. This involves writing down the specific reagents used, the time points measured, and having a detailed procedure for each experiment. When you have this level of documentation, you can successfully replicate experiments. It also provides a clear understanding of what parts can be modified to enhance the outcome of the experiment. An organized documentation is an absolute necessity in scientific research.

Modifying variables one-by-one shows the influence each has on the outcome, however with many variables the testing can become long winded and very cost inefficient. An alternative strategy is to use the Taguchi methodology where a series of tests are run where multiple variables are changed for each test in a pre-planned system. The test result then shows which variable has the greatest effect on the system output. With the Taguchi method, the tests have to be properly designed.

Uma dica importante, entre as itera??es e triplicatas ,seja na valida??o ou produtividade, é documentar algum desvio. Nesse sentido, é interessante anotar resultados errados ou n?o previsíveis. Nesse aspecto abre possibilidades de redu??o de erros, comparar eventos e resultados similares para compor solu??es de contorno. Muitos esquecem de documentar o que deu errado ( resultado n?o esperado ou indesejável) e só registra o que deu certo.

Los desafíos siempre están a la orden del día en un país como el mio (Argentina), la necesidad de resolver problemas urgentes por desabastecimiento o costos nos convierte en desafiar constantemente los planes habituales de homologacion, es por ello q es clave ser ordenados, respetar canales de comunicación y ser claros nos ayuda a optimizar los tiempos y recursos. Saltarse etapas de un proceso de homologacion puede salir caro y suele hacerse por urgencias, es por ello q ante esta posibilidad, debe evaluarse y no tomarse a la ligera el descartar alguna etapa, ver pro y contras, así como garantizar la performance de un insumo.

What does it take to visualize data? Simplistically, it is what gets the information to the stakeholders. That simple statement expands to there is no cookie cutter template. In simple cases, it is simple- maybe a sentence with a graph. In extremely complicated and inter tangled problems you might need more. Visualization, and I would add proper and truthful representation of data, is not fully understood or purposefully ignored by a flood of professionals that should otherwise know better…

Communication is very, very important yet this is not systemically taught to researchers. There is an art and science to communicating data effectively, especially on complex data and cross-functional subjects. In addition, depending on the audience, the content needs to be adjusted to resonate well with a specific audience. Much good research is not utilized nor appreciated simply because the audience cannot follow.

Communicate the results transparently, providing comprehensive insights to stakeholders and fostering a shared understanding of the outcomes.

Also: 1) document lesson's learned in a central repository 2) create a plan to improve upon the above 3) assign improvement owners and track progress

The most important factor to consider in communicating your results is "who is your target audience". Start there and work backwards...

Be clear on what you want to demonstrate/prove from the test; what properties or product function/performance attributes do you want to measure and what is the simplest way of measuring that. Start with simple tests that can measure effect of varying one or two factors at a time before moving on to more complex tests to measure synergistic effects. In other words, have a series of fast and cheap screening tests to allow you to iterate quickly and only do complex time consuming tests when the design is relatively mature. And remember that every test should be relevant to end application and what matters to the end user to provide quality assurance.

you should repeate more than 10 times. You should have a clear negative and positive control. You should be very careful extrapolating from an animal/cell system to the human situation. Actually you should have clear human Ph 2 clinical data with positive/ negative control before emphasizing about any success/value of any pharmaceutical product.

Here are some tips to design better experiment: Choose an appropriate design: (e.g., randomized controlled trials, A/B testing, etc.) that suits your objectives. Control groups: If applicable, include control groups to compare results against. Replication: Plan for replicates to ensure reliability and repeatability of results.

Detailing accurately each test iteration set-up/process is just as important as the test results. It is not uncommon to obtain some promising result from an experiment just to find out that you can’t repeat it because your documentation was incomplete such as material lots or sources or calibration or a host of other inputs.