This file type includes high resolution graphics and schematics when applicable.
Since Carnegie Mellon University founded its Software Engineering Institute in the 1980s and introduced its "Capability Maturity Model (CMM)" process, maturity has been both a subject of study and practice around the world. While generally applicable to all engineering disciplines, it has been most widely applied and practiced in software engineering. To be selected as a supplier of defense and mission-critical systems, or as a supplier to the medical and other life-and-death industries, companies must be certified at a high level of maturity.
While I've been on board with this body of knowledge since its inception, I've always found it to be insufficient for really getting at the business of making money from investments in R&D. The CMM is a "project-level" or "product-level" definition of maturity.
In "Measuring Product Development Effectiveness," I described different business functions as being mature or immature. Now I will address maturity measurement from a business-level view for the currently immature functions of R&D and product development.
How many times have you heard managers say they have no idea if a product will actually sell once it is launched? How many times in your career have you heard management lament that their new product releases are not producing the intended revenues or profits? These comments are a direct statement about business-level process maturity. A company should—and eventually will—be able to predict revenues and profits from new products with certainty. It is just a matter of time. The realization of "big data" and "data analytics" in the years ahead will go a long way toward creating confidence and reliability regarding the outcomes of new product and portfolio plans.
John Trudel's "Tales From A Skunk Works" column in Electronic Design (Machine Design's sister publication) got me thinking about this years ago. In December 1993, Trudel cited improvement from 30% success in 1968 to 53% success in 1993. Over the past 25 years, most cross-industry studies show the same approximate success figures. Not much progress has been made. Yet, every year when management approves the plan for the year, they still expect close to 100% of their approved projects to be business successes. Go figure.
Of course, no company actually wants 100% success from new products. Think about it. If engineers and managers were directed to design to commercial certainty, they would immediately dumb-down all designs so that every development would launch and produce some revenues. Business-plan projections would shrink as risk, uncertainty, and attempted innovations were removed to create certainty.
So, what then is business-level product development maturity? It is the ability to plan a portfolio of products and associated projects, and to know what the expected revenues and profits will be from the portfolio as a whole, within a few percentage points of plan. There has to be an allowable margin of error because the ability to predict competition and global economics is even less mature, and product developers can't be held responsible for that.
This definition of maturity provides the flexibility to differentiate across industries and for different company strategies within each industry. Innovators, about 5% of all companies, take big risks and expect low success rates. Technology and consumer product companies often fall into this category. The few successes, however, are usually giant revenue/profit producers. Companies with balanced portfolio strategies should expect success rates similar to those described by John Trudel. Fast-follower strategies should expect high success rates with less upside potential per product launched.
Focusing big data and analytics in the years ahead on quantifying expected year-over-year new product portfolio success rates would have tangible benefits. External Wall Street analysts are increasingly focused on the financial performance of new products. Companies that forecast well get treated well. Internal managers will be less inclined to overload the pipeline if they have confidence in the results they will get from a chosen set of products.
This file type includes high resolution graphics and schematics when applicable.