Driving Innovation in the Large Organization

By Douglas Hartung
Director, Global Software Research & Strategy
Diebold, Incorporated

“We need to be more innovative” is a rallying cry heard frequently throughout large organizations across industries.  Unfortunately, we often see the capabilities and processes that created past growth can act to hamper new innovation unless recognized and managed effectively.  In this article we will explore two ways large companies often let their existing organizational structure and processes stifle their organic innovation capabilities and explore how to work around these constraints.

Product Development is Different from Product Incubation

At some point in their development, most organizations have missed launch windows, overspent to reengineer products when important features were missing, launched a product unprofitably when pricing expectations were not met, or encountered any number of reasons a product launch was not considered successful.  Frequently, these types of mistakes can be caught early in the process when subject matter experts are engaged. This mentality often leads to the formation of New Product Initiative Committees or other forms of cross-functional teams assembled to ensure that all business, sales, technical, and operational aspects have been considered as a new product moves through the development process.

This activity can be exceptionally valuable as part of the product development process.  But this activity can also be detrimental to the rapid prototyping and testing of a “minimally viable product” as part of the Product Incubation process.  

• It is important to keep an eye on the most critical questions to be answered as part of the incubation process:
• Is there a clear problem that is solved here?
• Is it a problem that is faced and articulated by a large group of customers?
• How is this problem being solved today?
• Is my solution to the problem demonstrably better?

The Product Incubation process must be focused on answering the WHO WHAT and WHY of a potential new product incubation project. The HOW and WHEN can be addressed later once the concept has been proven in a less formal and operationally rigorous setting.  This is not to suggest that operational excellence is unimportant. It is. It’s just not important yet.

Project Management vs. Portfolio Management

Product Development in large organizations frequently follows a fairly traditional path.  A business case is developed, business requirements are defined, a business analyst translates these to functional requirements, which drive out technical and operational requirements.  We progress down a path of approving the requirements, moving to development, then testing, and then launching.  Stopping anywhere along this path is seen as failure or wasted effort.  The mindset: We are running a project through to completion or we are failing.

Managing an innovation program is more about Portfolio Management.  (And moving beyond the deploy or fail mindset) A lesson learned early in my career was when I was asked by a participating VP if I thought a particular initiative was going to be a big success.  My response was that of the ten innovation projects we were managing I was fairly certain that 5-6 would fail, 3-4 would be marginally valuable, and 1-2 would be a big success.  I suggested that if I could know which two would be profitable I’d stop work on the rest of them. But rather than grade me based on my guessing skills, let’s judge performance based on whether we quickly identify weaker projects and quickly repurpose resources towards other projects and activities quickly, and determine if the small number of successes generates returns sufficient given the overall cost of the innovation portfolio.  Admittedly, this can feel like a very odd way to view the world in many settings.  It certainly felt odd to the VP who wanted to judge success or failure on a per project basis (and you better hit 100%!)

John F. Kennedy is purported to have said that success has many fathers but failure is an orphan.  This is particularly true in corporate new product development settings. But it needs to change:  fail early, fail often, fail cheaply, capture the learnings and move on.

One way to make failure part of the process is by overtly planning for failure.  Ways to make this a part of the process include using one of the following two tools:

• Require that any new product concept being developed include a short section that includes (a) “if this project fails it is likely to fail for one of these reasons”, and (b) “here is what we are putting in place to ensure that we are watching for these reasons and what we will do if we encounter them”.  
• Steal a page from the medical and military communities.  You probably don’t want to call it a Morbidity & Mortality Conference to learn why the project died.  But creating a simple Lessons Learned document can be invaluable both for capturing learnings for future use but also as a mechanism for changing culture to look for and learn from these “failures” as an expected part of the innovation process.  

There are numerous examples of large companies that excel at managing a portfolio of product innovation concepts as part of the process of new product development.  And without question the product innovation process is a critical front end to ensuring that products brought into the development process are feasible and attractive to the customer.  But these two activities require a very different approach and cultural orientation to work together effectively.  Focusing on the key foundational success factors (what problem is solved, and why is this solution better?) and managing an innovation portfolio rather than discrete, “over-structured” projects, are just two of these important differences. 

Douglas Hartung joined Diebold, Incorporated in 2014 and is the director of global software research and strategy. In this role, he is responsible for identifying, leading and evangelizing new business and product ventures to expand Diebold’s software portfolio.