BRIEFING – ORGANIZING YOUR R&D PROCCESS

This is a series of practical posts, to help the visionaries who are organizing their R&D departments. You know, don’t you? Organizing in order to conquer: An organized process allows you to see possibilities of improvement, bottlenecks and possibilities of convergence.

In the first post in this series we talked about project management and planning – and you can use our free tool to organize that mountain of projects that you run at the same time.

Now let’s talk about the project opening document – the briefing.

BRIEFING-DEFINITION

A synonym for briefing is “instruction”. The proposal here is to collect all the relevant information for the project – for example, the conception of design – which will be used by the R&D team to transform the idea into a product/service afterwards.

BRIEFING – CONTENT

The content varies greatly from one company to another – there isn’t really right and wrong here. However, there are some pieces of information that are most commonly found in business briefings in general.

Do you want a benchmark? Here it goes:

• Project objective
• Desired final price (or range) and estimated volume of sales
• Requester
• Request Date + desired project completion date
• Type of delivery to be carried out (sample, prototype, report, presentation, pilot launch, etc.)
• Target market (or target user, or person, if we are already employing design thinking) and its main features
• Functionality requirements (textures, color, flavor, portion, aspect, conservation, etc.)
• Desired packaging – Primary, secondary and transportation/storage structures
• Important restrictions imposed by the user, legislation, market or others.

These are just the most common options. Analyze your case: what information is needed to start a project?

If you work with R&D of ingredients, it is probable that you need a guidance formulation of the food in which your ingredient should be applied. Working with final products, you may need to know beforehand if the project should include the sensory analysis team.

To define what information to put in your briefing, think about your past projects: at what time did you have to stop everything, go back to the requester and ask for more information? That information should go to the briefing.

BRIEFING – WHO FILLS IT?

It depends. Traditional logic says that requester should fill the briefing, but the requester might vary. It could be commercial team, the owner of the company, the Marketing guy.

However, if you are already using design thinking, and if your structure already integrates the roles of marketing and R&D in a same team (with maybe some product designers to break some paradigms?), maybe you will fill it yourself.

The briefing must be filled by the person who is closest to the user, because it is the document that registers the unattended desires of the user, their expectations and perceptions, the attributes and functionalities of the product/service and the constraints of the project. Normally, we are excellent in registering the last three groups of information, and we leave the unattended wishes blank.

Big mistake. Très grand.

(We’ll talk a little more about that shortly, don’t panic)

BRIEFING – HOW TO USE

As from the briefing, a very entertaining (#not) part of the project begins – developing formulation, packaging, process to suit your goal. The food visionaries will use all their knowledge and experience to translate that idea into something tangible.

If your company has a good project database, it’s time to search it through and find a similar project to be used as a starting point. If it doesn’t, how about creating one?

If you need to start the formulation from scratch, it might be nice to read this post on how to create your first food formulation.

BRIEFING – WHAT CAN GO WRONG?

If you still do not use a document to register the beginning of the R&D process, it is likely that the first document is incomplete. That is, you will reach a certain point of the project and need to return to the requester (or your notes from the ideation sessions) with more questions.

No problem: Register the questions asked and consider whether they are frequent enough to be incorporated into the briefing.

The biggest problem, however, happens in the registration of the user’s unattended desires. Because that input hardly ever occurs. No wonder so many companies have not succeeded in their launchings – the world is full of half-decent products being aimed for space, only to then just land on the ground.

We are very good at defining explicit user expectations: What price, color, flavor, portion, packaging he or she desires, all based on what they are currently accustomed to find on the market. We’re great at copying what already exists. We are particularly excellent in defining the constraints of the project: “Cannot” is expression of order.

We’re terrible at defining what he desires and still doesn’t have. After all, we need to use tons of empathy and observation capability, which are not the most abundant competences around us, isn’t it, visionaries?

There is no problem in copying, if you want to be merely another cheap option. Now, if your company intends to win the game, it doesn’t make sense to offer what already exists – because that won’t change the user’s life, and it will never make him a ardent fan of your product.

Because of things like that we have a myth – propagated by some of the most innovative minds in our world – that the consumer does not know what he wants. I say: yes he does: put in front of him something that solves his life in a complete, safe, creative, ergonomic, helpful way, and see if he doesn’t know how to define very well that this product is what he needs.

So what can go wrong: because the briefing is a form which aims to organize the initial ideas about the project, is tempting to focus on what can be measured, weighed, priced and visually compared. Do your work, visionary: strive to define, in each project, an unattended desire of your user. Strive to understand how we can improve the user experience with that category of products and services – maybe a product with an even larger layer of services around it?

BRIEFING – CAN YOU CHANGE IT IN THE MIDDLE OF THE PROJECT?

Ah, the oldest of R&D questions: Can I change my input requirements? There are several strands of thought on that. Here I propose a reflection based on personal experience.

If the change is not significant in relation to the project’s main attributes AND if the work of R&D accomplished until then is small, the briefing can and SHOULD be adjusted as the understanding of our user improves;

However: if the change is significant OR the work of R&D accomplished until there is big, it’s better open new briefing and register a new project, canceling the previous one.

Why I say that: the briefing is, ultimately, the conductor of the work of R&D. It must be the starting point and make sense in relation to the path that the R&D took. Understanding the R&D process as a beginning, middle and end (and iterations) is basically understanding that path.

After two years, when you’ll need to return to that project as a basis for a new product, it will make more sense that abrupt trajectory changes are recorded in a complementary project.

BRIEFING – AND WHAT TO DO AT THE END OF THE PROJECT?

When the project is finished, we just deliver it for the factory to produce? No!

When the project is finished, you must go back to the briefing and verify that all that was requested was answered. It is a good practice to explicitly reserve a time on the project schedule for this confirmation (even if it is 20 minutes). I’ve already had my share of “finalized” projects that failed to deliver certain requests that were on the briefing “by mistake”.

In other words, they were not finalized.

Now I want to know about the visionaries who read the page: What are the information that a project briefing for food R&D cannot fail to include?

Comment here what you think about it, will be a pleasure to hear you.