Once in a while we get to deliver a product or a feature to our customers, be it a simple light bulb or the most complicated space-shuttle the Space Agency has to offer. In R&D you may say that the road to the product is our day-to-day in the trenches and the first product units reaching the client is the victory march in the streets of the capital. Nevertheless, the R&D does not stop in those successful first units. The final R&D step in a certain life-cycle iteration is the transfer from development to production.
In other words when the know-how of manufacturing, delivering, installing and maintaining the product goes out from the R&D to the relevant disciplines, hand the keys over to the Sustain System Engineering department and leave the R&D teams to develop the next gen. In our military example, the R&D finishes when all treaties are signed by the official leaders and we know for sure that the troops do not need to run back to fight in the trenches.
What is this process? As the name suggests it is a process of data-transfer between the R&D and other disciplines in the company. Note that just as there are no two companies that are exactly the same, this transfer from development to production process differs from company to company and even from product to product. Having said that, I will try to give as many best-practices and tips that apply to nearly all cases.
An important disclaimer: SW only systems or SW only upgrades are not in the scope of this post. There are so many methodologies for transfer to production like CI/CD, staging, partial updates and so on. Most methodologies apply also to multidisciplinary systems in the cases where only SW updates are to be executed (bug fix, soft features etc.) but these will not be the cases we will be referring to in this post.
Main Differences between R&D Units Manufacturing and Production
Manufacturing R&D units, even if they end up at the customer’s place, is not the same as Production and it is not just a matter of quantities. In R&D units we have the freedom to make changes as we go along. Production does not work that way – there is a recipe, a procedure, a flow. All units must go through the same flow and end up inside a specified specification. But there is more to it than just that, as can be seen in the following table:
If we could sum-up the table above into a short sentence it would be that the R&D units are made and maintained to work while the production units are being manufactured 
.
Development vs. Production Disciplines
As mentioned in previous posts, each phase in the product life cycle requires different personnel and different role involvement.
The relevant disciplines that participate on both sides of the transfer are as follows:
Project Management Transfer
It really depends on the hierarchy in the organization, but usually the management for the production phase is different to that of the R&D phase so the usual shift would be from Project Management to Production Management or Product Management. Remember Sales & Marketing also have to rise to the occasion, so in some companies some of the management responsibility goes their way.
Because generally the priorities-state-of-mind changes when transferring to Production the management team usually changes with it to those who are better equipped to deal with these changes.
Engineering Transfer
That almost goes without saying – R&D System Engineering transfers to Sustain System Engineering, again because of the change in the state-of-mind. In many cases, especially in smaller organizations, the same person escorts the System Engineering activities before and after the transfer until some other discipline takes over the Engineering responsibilities.
The other core R&D team members will need to participate in the knowledge transfer as listed below, but a one-to-one personal discipline transfer is less common.
Note that only in very large organizations there are dedicated R&D teams (SW, HW, Mech etc.) to handle sustain tasks. Usually there is a (small) percentage of time dedicated to sustain tasks within the different R&D teams and these are orchestrated by the relevant System Engineer.
Integration Transfer
To make sure we are on the same page, a quick terminology definition relevant to this post: in R&D, Integration refers to the function that has its hands on the tool at all times – the one who assembles, aligns, services and maintains the systems as long as they are under the responsibility of R&D. In some organizations the team that assembles the tools in Production are also referred to as “Integrators” – we will refer to this team as Production to avoid confusion.
The Integration team, who served as some kind of a do-it-all, have to transfer their accumulated knowledge to at least 3 disciplines: Production, Service & Support and Packaging (if separated from Production) all with the kind help of Engineering and a technical writer.
Supply-Chain Transfer
Once again, in a large enough organization, the Supply-Chain will be divided into divisions that work solely with R&D and the ones that work with Production. The more general case is where the Supply-Chain team changes the relevant items in their lists from “R&D” to “Production”, update Procurement (sometimes also termed as “Purchasing”) of their existence and start purchasing
plan according to sales and manufacturing plans.
Indirect Transfer
Note there are more disciplines such as New Product Introduction (NPI), Finance, Training dept. etc., that should be involved in the transfer from Development to Production but these are not involved in a direct transfer from any R&D discipline.
Transfer From Development to Production – Timing
The first dilemma we have to address almost everywhere is the timing of the transfer or at least when to start involving the production disciplines in the details of the R&D process. We are all aware that whatever happens when growth phase starts the transfer has to be at the finish line.
There is not one good answer to this timing puzzle as there are many aspects to consider as follows:
- When R&D and Production personnel overlap the transfer is obviously less formal. However, a very undesirable common by-product of this case is lack of proper procedures and documentation because the information resides inside the heads of the team members and that is until it doesn’t… or until one of the team members leaves the organization.
- If none of the teams involved has the bandwidth to support the activities of the transfer, it will simply be neglected. This is probably the number one reason for reaching growth phase in a project when the transfer is by no means close to be concluded and the main reason why in many organizations the R&D team is deep inside solving manufacturing issues instead of moving forward and developing the next gen product.
- Starting the transfer too early, e.g. when there are still a lot of changes in the architecture and/or the procedures are far from finalized. The problem with such involvement of Production would be the need to redo the transfer again at the end of the process.
- Starting the transfer process too late such that there is not enough time for the data to be transferred properly
There is a rule of a thumb for the correct timing to start the transfer. In an R&D process that is about to include the build-up of N units, start having the Production with you towards the last third i.e. from the 2/3xNth unit. That’s when you would also want to start writing your procedures.
In the cases where the R&D builds only one or two systems, consider defining the transition to after ramp-up to full production has already begun, where the knowledge exchange would be like on-the-job training. Try not to get there because “things happen” but plan ahead for this option.
What is the Content of the Transfer
I have encountered a number of cases where the teams did not know what info had to be communicated between the two sides. The following list details a clear picture of that exchange:
What System to Manufacture
As literal as possible. I do not mean to inform the Production department of a car manufacturer company that we are going to make new cars – I assume they did not expect us to start manufacturing dining tables , but I would expect to detail what are the changes from last gen product, what has deprecated and why. In our car manufacturer example, we are going from gas to electric and that the windows are no longer manual is valuable information that must be delivered.
System Specifications
Going to Production without a clear view of what are the product’s final specs is very dangerous and slippery path. Even if we are not sure we have to provide something to enable the Production to verify the different units’ performance and compare them to one another. Without which each unit is going to have different performance and each client is going to be satisfied or dissatisfied accordingly.
How to Manufacture the System
BOM trees & vendor list, SW documentations, tools, flows, procedures, drawings, sketches, decision trees, training and all you can think of that is needed for repeatably and reliably build and manufacture the system. If our new car piston must be assembled inside a clean room hood, unless this information is clearly conveyed to the Production team there is no way for them to know that. In most cases we do not have everything ready in-time but try to have as much as possible available otherwise the R&D will spend a lot of needless time and effort doing things they ideally shouldn’t have.
How to Test the System Performance
Testing methods, their expected results and pass/fail criteria are imperative. Without this data there is no way for the Production team to understand if the assembly and alignment/calibration are correct. Remember, a test without clear acceptance criteria is useless for a unit production (let’s keep data-collection for statistics aside for the sake of this post).
How to Package, Ship & Store the System
What kind of packaging is needed, which materials are allowed, does it need protection, sensitivity to heat or humidity during shipment, plane or boat and so on. These topics tend to be a black hole especially when we are already in advanced versions of a certain product and where a lot of the manufacturing flows and processes are based on older generation products. In each new gen these topics should be revisited even if only to find out that the instructions remain unchanged. Remember that a lot has changed over the past 10 years when it comes to shipping standards and as such you may discover that you can significantly lower the shipping costs.
How to Service & Maintain the System
Once again, in a brand new technology or a product this topic may be problematic since our knowledge and know-how extend only to the period of the product development and the maintenance or troubleshooting we conducted during that period. Nevertheless, if we go back to the car manufacturing example, we know from the wheel manufacturer that the breaks should be replaced every 15,000km so also include this information in our documentation. You’d be surprised how many important pieces of required information can be gleaned just from reading the service manuals of the elements used in your brand-new system.
Bear in mind, though that even if you’ve done the transfer from Development to Production perfectly, you will still have to return to assist here and there for different kinds of errors and issues only because these were not foreseen or known before and need an expert’s advice.
Known Issues
If there is one piece of advice I wish to share in this post and is usually overlooked it is to keep a list of known issues that were raised (and hopefully solved) during R&D and pass them on to Production in the transfer process. This list is a gold mine in terms of know-how and knowledge and is incredibly useful in the rare cases where after 3 weeks of intensive troubleshooting you try to find the veteran engineers in the cafeteria to ask them whether they know of such-and-such problem only to find out they had encountered it and solved it almost in day one. Try to save this stress from your successors.
Caution: beware of TL;DR. On the one hand, you do not want to burden yourself with a lot irrelevant information and then force your intended audience to read it while on the other hand, in data pass-down such as Dev to Production transfer neglecting information or summarizing it without some to-be-crucial information would make your TL;DR dangerously negligent. Choose what info to skip, what to detail and what to summarize very carefully.
Development with Production in Mind
There is one point that can make the whole process of transfer to Production much smoother – have Production in mind or even in the room while developing. It is a good notion to share the assembly and alignment flow, service strategy and so on with Production representatives from the concept stages in the design. Using their advice will surely avoid any catastrophes when it comes to manufacturing and service processes. This would also give you inputs on current products’ difficulties and problems that you may solve in your current design.
Make sure though not to let the Production whims take over the end goal of the project. Let Sustain solve these day-to-day problems in the cases where they are urgent to keep you focused on your own task.
To sum up, the process of transferring the product from R&D to Production is an inseparable part of the product-life-cycle. It may go smoothly and unnoticed as part of our day-to-day work and we may need to carve it into our schedule in order to get to it and do it correctly. Either way, we must do our best to deliver all the relevant information to allow the product-life-cycle flow to continue as smoothly as possible.