There are two ways to obtain new, product-enabling technologies; 1) buy or license a new technology from someone else, aka external acquisition, and 2) develop your own proprietary technologies using your own people and resources, aka internal organic development. Executives often have a bias towards acquisition, hoping to incur little or no development costs and believing the cycle time for obtaining it is relatively short. On the other hand, internal organic technology development takes a lot of resources; people, time, material and support. Running technology development projects requires similar skills, resources and best practices as modern product and process development.
Over my career, I have noticed a pattern of beliefs in organizations that buy technologies from someone else; 1) they believe what they are buying is ready for commercialization, assuming they will realize cash flow from the product into which the new technology is going within 6 months to a year, 2) they believe the technology is mature and capable of integration with their existing subsystems and, 3) they believe that funding internal technology development is a bad financial bet when compared to acquisition. What do these beliefs lead to? Read on...
Is it Really "Ready-to-Go"?
I rarely see acquired technology that is "ready to go". It is typical to see the hoped for 6-12 month commercialization time-line slip into 24-36 months of what I call "Technology Scrap and Re-Work projects". Consider the organization that produced the acquired technology. Small, "nimble" teams or organizations (think college professor turned entrepreneur with the help of graduate students) will most likely lack system engineering and integration skills, product and process development skills. This may be the first time they have ever developed a technology to sell and probably did not use a proven, disciplined technology development process. They don't really know how to control their new technology well enough to say it's ready to go.
How Much Do You Really Know About Your Intended Purchase?
During due diligence studies and acquisition negotiations you will find many unanswered questions and gaps usually controlled by the legal team acting in the interest of the seller. The metrics used in technology acquisition are purposely kept very general to prevent actual detection of serious issues, short-falls and functional problems. In many cases, the sellers have no clue as to the ticking time bombs they have created for the down-stream product developers. The usual "risk analysis" used by the buyer is a weak substitute for hardball, data-based metrics that dig deep into the functional mechanisms behind robust and tunable performance windows that directly relate to the hoped-for new product. So the acquisition team generates a best guess based upon perceived risks versus a fact-based knowledge of the real problems that the new technology poses in the real application context. In every situation I have observed, the buyer of the new technology is unpleasantly surprised by just how under-developed and incapable and over-sensitive their new technology is once they have paid for it!
Regardless of Make/Buy, You Need a Competent In-House Tech Dev Team & Process
As a result of the above-mentioned problems, the "make vs. buy" decision should be re-framed. A bottoms-up comparison should be developed for the value of an internal team that has core competencies in innovation, invention, technology task and best practice execution excellence with the discipline of a well-designed technology development process.
I'm suggesting that you invest in in-house expert and repeatable--like a pro golfer--capability and competence to develop outstanding, commercialization-ready technologies synchronously with your strategic product portfolio planning process and your product/process development process. This is a 3-link development process model:
Portfolio >>> Technology >>> Product/Process
You should be an expert (not an amateur) at all three of these processes. An expert internal technology development team will easily out-perform and external group of amateurs.
Even if you do buy technology from someone else, you absolutely must have the internal Technology Development team ready to finish the technology development. 3M is great at this; I worked with them to deploy this strategy--Buy it for cheap and then do the following things....
Consider developing a detailed technology development process enabled by PDSS' distinct model for conducting Critical Parameter Development and Management. The governing metrics for any new technology's maturity and safety for transfer to new product/process development are the Big 7 Critical Parameter metrics we continually recommend:
Are the Subsystem and Subassembly FUNCTIONS and Part and Material CHARACTERISTICS meeting or falling short of these metrics:
- Measurable?
- Stable?
- Adjustable?
- Independent or interactive?
- Hyper-sensitive?
- Robust?
- Capable (Cp & Cpk)?
Next time you externally buy or internally develop a new technology, hold it up to these metrics and ask the 7 questions... do we know, based upon sufficient sample data, whether the technology passes or fails these standards?
A strong technology development process has the tasks, tools and best practices and reviews built into it to assure you can answer these 7 questions. If you design your work flow to prevent problems along this continuum of learning, you will be doing the best we know to do technology development and transfer right the first time!
