FTTM Innovation
/Ideas to stimulate discussion about how to better manage path-finding development
Recently an executive asked us, “We're not a research company per se and need to benchmark how "think tanks" estimate innovation durations/cycles of learning that require major breakthroughs.”We assembled this document to stimulate group discussion (within the client’s various advanced development teams). It is not meant to draw conclusions or converge on any specific actions, just to get people thinking and talking. 
Team Domain
Learning means failing. Failing means learning. Failing quickly means learning quickly. The faster you fail, the faster you learn. Through failure one learns, and learning allows you to find a solution to the problem faster. The logic follows that the faster you fail, the faster you learn. More chances to fail equate to more learning cycles. In order to get more chances to fail/learn, the cycle time needs to be shorter (faster).
Successful innovation environments are designed to give teams more cycles (usually means more resources) and then they spend a good deal of time trying to find ways of accelerating the cycle-time of each cycle. Cycle-time compression also permits more cycles in a given time span.
Steering Committee Domain
Fast innovation cultures design for speed and teams are provisioned for speed. They get what they need because people know that the cost-of-delay far exceeds the cost of investment. They spend to save a day. This often translates to needing more people to design and analyze experiments, more dedicated tools to run tests, more material to test various combinations, more access to external information in Universities and professional groups and more access to consultants and topic experts, etc. This investment is very small in comparison to the cost (loss in revenue and profit) of being late to market.
The team sets up projects to concentrate risk versus disperse risk across the project/product. The resources are brought to bare on the concentrated risk areas in terms of dedicated and co-located teams of experts. They are freed from the interrupts of company “overhead” (meetings, reporting, managing people, reviews, etc.). They are allowed to start early in order to get more time, rather than on the late-schedule and then forced to innovate when there is a crisis or when they are short of resources.
Management avoids “group fixation” on the most difficult problems. The tendency on bleeding edge path-finding development is for the complete team to expect the long-pole problem to slip and get longer. This causes the other parts of the project to “relax” and not have a sense of urgency. The logic is that if “we can’t solve x problem, then it is not worth doing anything else.”
In fast innovation environments, the mindset is quite different. They assume the long pole is going to get shorter, so they drive multiple simultaneous innovation paths to accelerate. They get 4-6 concurrent paths competing to get faster. 
Challenge Current Thinking
Breakthroughs are achieved when people think differently. When they challenge paradigms, new ways of approaching problems are exposed. The tendency in advanced development is to follow conventional thinking and to get people to “think harder.” Most innovation comes from looking at the problem from a entirely different perspective. Teams need a mechanism and permission to do this, because just “saying it” does not make it happen. People need to be permitted to challenge current thinking
This is difficult because the current thinking is vested in the thinkers who promoted it. It is worse when these experts also have position power. Challenging them has organizational and hierarchical implications, which is why it is hard to do and why people typically decide against this career limiting behavior.
Edward De Bono’s Lateral Thinkingtechnique called “Challenge” provides such vehicle/mechanism for alternative thinking. We’ve adapted it for our use (above). There are strategic and tactical breakthroughs. These come in terms of schedule, but more importantly in the form of technical solutions that drive schedule innovation/speed.
The project team needs to implement a regular process for challenging assumptions and dominant ideas about the direction of development. This process gives people the “permission” to question the “sacred cows” of thought. This is not a personal challenge, but a thought challenge. Are the current solutioning paths the right ones? Should there be more/less or different ones? Are the original assumptions made three years ago still valid? What if a current direction was killed in favor of a totally different one?
The technical innovations/solutions that the project needs today in order to commercialize the technology tomorrow are going to be found in places that you are not aware of today. One technique for exploring this space is to challenge everything that has been done to-date in a constructive formal and logical process. This is something fast innovators to on a regular basis and they build this into the iterative evolution of their thinking throughout the life of the project.
Bring in external thinkers working on the topic and also thinkers in unrelated disciplines as consultants to challenge your technical (vertical) thinking. These “thinkers” tend to be free of the current thinking of the project and are therefore able to bring a different perspective. A majority of the innovation we’ve observed came from people outside of the subject matter, since these people are unencumbered by the paradigms of conventional thinking (Non Impediti Ratione Cogitationis).
Cycles of Learning
Following are 3 slides that illustrate that learning cycles can, in fact, be programmed and scheduled. The unknown can be scheduled if the planner is willing to be roughly right (versus exactly wrong), and to use base assumptions as a starting point, and then iterate using new information learned from the pervious cycle to adjust the next cycle. It is basic, yet difficult to get people to grasp the concept of planning “what you don’t know.” Not making the attempt is just being lazy.
Questions for group discussion
The list below could be a starting point for brainstorming discussions.
Increasing the number of learning cycles and reducing the learning cycle-time will increase the chances of finding solutions and/or cause failure faster, which could lead to accelerated learning, but this in itself does not generate faster innovation, yet it can help in scheduling innovation in that it provides a better predictive model of duration (based on current assumptions and actual past performance). Looking at the planning problem is necessary but not sufficient.
System Architect
A major opportunity for changing the way people think about innovation on a program is in how the groups of people working on problems have been organized. Are they organized for lateral solutioning or are they sub-optimizing inside their technical/functional silo? What systems are in place for cross-discipline communication?
Most breakthrough solutions on difficult problems come from the a deep understanding of the interfaces between things, not necessarily within the technical subject matter silos. Do team members have “systems thinking” skills? The trick is to understand the SYSTEM interfaces and the STSTEM within which it operates.
Have you structure the teams to manage the “system” and the interfaces within it or is it designed to optimize each independent technology/function? Do you have a “systems architect” for the project -- the person making system level trade-offs and managing those interface points? What is needed to raise the level of systems understanding on your program and empower fast trade-offs?
In the example (above) from a client project (it has been sanitized to remove client references). This was a bleeding edge semiconductor-type complex process that involved development of a new manufacturing process, new tools, new use of materials, and a new end product that was a major performance breakthrough -- it had the potential to disrupt an industry. It was staffed with the brightest minds in this field.
Like most complex developments, it had been compartmentalized and the functional silo walls were high and thick. The project lacked someone managing the lateral interfaces. The solution was eventually found in the white space between the silos, as in all complex systems it is about making the right trade-offs and understanding the knock-on impact of those across the system in terms of cost and performance.
This example is offered in order to stimulate ideas. It may not exactly be your problem, but could the concept be extended to the way you are looking at your project today? What new thinking or insights can be extracted from this example for use on your project?
The challenge for the team/organization is to move from problem identification to actually doing something to cause a change. This “actioning” part is always the hardest, especially when the way forward is less clear. But this is the iterative reality of a path-finding projects.
The greatest challenge to any thinker is stating the problem in a way that will allow a solution. (Bertrand Russell)
Our willingness to fail gives us the ability and opportunity to succeed where others may fear to tread.(unknown)
Everything should be kept as simple as possible, but no simpler. (Einstein)
I've missed more than 9000 shots in my career. I've lost almost 300 games. Twenty six times, I've been trusted to take the game-winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed. (Michael Jordan)