Insight No.42 : Oct 2012 : Organizing Chaos: Innovation ManagementManaging the Non-Linear Progress of Innovation: Lessons on Balancing Freedom and Discipline in R&D Programsby Stefan Stuerwald
Innovation programs are, by their very nature, unpredictable. Leading a diverse team of researchers charged with a mission to discover something genuinely new - while keeping to a fixed timeframe - requires a unique balance of freedom and discipline. Managing an innovation program successfully can reap unexpected benefits, however. Pcubed's program management approach to innovation recently helped one international research and development team discover an ambitious new solution within a quarter of the time expected, taking just six months to come up with the kind of answer that usually takes two years to produce. This project has a wealth of lessons that can be applied across a range of other innovation programs.
The Challenge:
Inventing the next generation of car batteries for the 21st century - realizing a vision of the future in which batteries do more than just crank the engine and power accessories, but actually help propel the car.
The Goal:
Paving the way to 20 percent greater fuel efficiency.
The Timescale:
Approximately 24 months.
In recent years the landscape of battery technology has been completely reshaped by the rapid development of hybrid and electric vehicles. OEMs, or Original Equipment Manufacturers, are demanding far more from the traditional battery than ever before. For longstanding players, it's a race against time to develop the next generation of fuel efficient batteries before their competitors.
Pcubed was engaged to manage the innovation program of a large manufacturer developing a prototype vehicle designed to showcase a new kind of battery for the 21st century. The stakes were high and the finish line was fixed: two demo vehicles with different battery technologies had to be ready to be test-driven by the President of the Business Unit in December 2012. How to get to that point, however, was left wide open for the researchers to explore. The mandate was to develop the best possible technical solution without the immediate pressures of product development or specific customer specs, while still keeping an eye toward overall market demands.
Getting to Grips with Non-linearity
R&D programs of this sort are a very different kind of undertaking from conventional production-focused program management practice. As scientists and engineers venture into unchartered territory in search of innovative new solutions, the detailed constraints of rigid project plans simply aren't appropriate. Learning to balance the need for freedom with discipline, creativity and scientific inspiration with hard deadlines requires a unique program management style.
Traditional production programs are linear - focused on costs and time. An R&D program, on the other hand, is concerned with "learnings," which don't generally occur in a linear fashion. At the start of the program, you have an idea of where you want to go - but you may not know exactly how to get there. Traditional production program structures would put the R&D program into a straightjacket - the high degree of ambiguity that defines an R&D program means researchers must be allowed to venture onto paths that may not always be successful. (See Example 1.)
Example 1: Flexibility and Risk Acceptance Go Hand in Hand
Flexibility was a key requirement throughout the program. As the drivetrain would include some prototype components, corporate business development was represented on the program core team to help utilize existing supplier and partner relationships to source those components. Some components simply weren't available, so the team had to brainstorm non-industry solutions, such as scouring manufacturers of amusement park rides, school bases, and agricultural tractors. The final prototype drivetrain is partially oversized as a result of these parts.
The design also required us to prototype those components that weren't available from any existing source. This step represented the greatest time commitment and risk during the program, complicated by the fact that we sourced components through an independent third party in order to maintain the anonymity of the client. Although we planned for prototyping in the program plan, we had not been able to identify the sources for the prototype builds or the component designs at the outset. The allotted lead time was therefore conservative, but still represented a significant risk. This risk was well communicated, understood, and accepted by steering team.
Successful program managers need to understand and embrace that non–linearity to provide the space for creative thinking. There's still goal for the end of the program, and a certain degree of discipline is needed to maintain focus, but it must be balanced with a level of freedom. The battery program was about creating a completely new kind of vehicle energy storage solution in the best traditions of blue sky thinking and research while adhering to a very concrete deadline.
Creating a Culture of Freedom
The successful R&D program manager will keep a close watch on the way team members interact to make sure people aren't slipping into a production-focused mindset. They need to develop a feeling for when the research team is trying to knock off a list in a goal-orientated fashion. That could be difference between simply getting something to work and learning something truly new.
In other words, the program manager needs patience. Specific stages of research might take much longer than expected; the team might need to experiment with a number of different ideas before they can get one to work. This needs to happen organically: typically a program manager would be telling the team to adhere to the timeline - but here, they have to know when to be flexible.
This also means research scientists need to be shielded from product engineering pressures to give them the space to explore best-of-breed concepts rather than re-iterations of existing solutions. We ensured that our R&D teams could work without being unduly influenced by "get-to market" pressures by physically removing them to work in a different location, although the voice of the customer was still represented on the steering team.
The goal of the program wasn't to manufacture production-ready components. Ultimately, if the cars start and succeed in running during their test drive for just a few yards before dying in clouds of smoke, the program would still have been a success, as long as the lessons learned allow for a second iteration of components. However, if the cars run well, but with only incremental learnings from well-known technology, it would have been a failure.
Creating a Plan - and Being Prepared To Rip It Up
So how can this delicate balance be created and maintained? For me, it's partly a question of mindset and partly a question of planning. The R&D program manager has to be prepared to adapt the program plan or even rip it up completely - it is not a failure to have to change it as the program progresses. Linear types of people can really struggle to adapt to non-linear ways of thinking; and non-linear thinkers are particularly hard to find among engineers.
Good planning is still essential, however. It just needs to be prepared with a higher number of assumptions and more imperfect information than might be typical. Risk assessments need to be conducted at the outset to define the likelihood of the anticipated issues and best predict the possible probability of things going wrong. With this high level of ambiguity, it must be accepted that the plan can never be perfect.
For my client on the battery innovation program, vehicle selection was driven by the desire to learn. The team purposefully selected BMWs because their complex electronics with multiple controllers transmitting a high volume of data would expose data that the team had not anticipated, both in modeling and testing. It was more difficult to find the vehicle's baseline, since adaptive algorithms allowed the car to "learn" certain conditions. As a result, greater iterations had to be run on some tests than anticipated until the car had reached a stable state (for example, fuel economy kept increasing as the car learned).
The high level of ambiguity involved means the R&D program plan needs to include plenty of buffer time to prepare for elements of failure. If something goes wrong, there's time to fix it. Of course, it's impossible to know when something will go wrong, and where, therefore, there needs to be a buffer. Certain elements can be identified as high risk - but sometimes these high risk stages go smoothly, and others are unexpectedly difficult. On the battery program, we were originally convinced the greatest risk to success would be in designing a new type of motor/generator to achieve higher levels of regenerative power than non-hybrid powertrains have traditionally been able to. As it turns out, the greatest risk was actually in the design of a seemingly much more evolutionary part embedded in the vehicle's traditional 12V storage system.
As a result, the critical path changed throughout the program as anticipated issues and bottlenecks were superseded by new ones. Of course, program managers still need to have a technical understanding of the amount of time a certain piece of work should take. There are exceptions, such as a major technical breakthrough, which causes the whole plan to change, but this is relatively rare. Most of the time, it's about incremental success.
An additional challenge faced by the battery innovation project was the composition of the team itself - a mix of internal scientists and external contract engineers, geographically disbursed across time zones and corporate networks. It was therefore vital to get everyone using a collaborative tool which everyone could access as soon as possible. (See Example 2.) A meeting cadence was set up to tie together a multi-layered team structure (shown in the table below). Pcubed implemented a three tier disciplined meeting cadence, which was lighter than it would have been for a traditional production program. This cadence was regularly re-evaluated during the course of the engagement to fine-tune the team's meeting load. Team members were asked to collaborate intensely one-on-one across specific skill sets to develop close relationships. In addition, we also stressed the importance of regular site visits, which were vital for discipline and knowledge transfer at crucial moments in the program.
Collaboration and Communication
Example 2: Desired Learnings: To Build Technical Understanding and the Infrastructure for Future Developments Simultaneously
The innovation program deliberately combined internal and external contract development teams. Initially, this created additional complexities. The team was geographically disbursed across time zones. We needed to establish a collaboration tool that worked across enterprise networks; cloud-based tools accelerated this step.
On the other hand, using outsourced engineering expertise provided us access to a specialized, capital-intensive test facility. It also allowed us to build the infrastructure for an internal bench test environment for future development work while installing the first iteration of the components in a vehicle.
Factors in Managing a Successful Innovation Program
| Team Structure |
| Multi-Layer Structure |
- One team approach across internal and outsourced resources
- Steering Team: Served as decision-making body and helped remove roadblocks, often on the spot; meetings not dominated by status updates
- Core Team: Stakeholders whose input was required during the program; involvement required at relevant times, not continuously
- Technical Team: Performed development work
|
| Meeting and Communications Cadence |
Separate Steering, Core, and Technical Team meetings
- Steering Team: Bi-weekly, standardized agenda with room for open discussion
- Core Team: Agenda-driven cadence, bi-weekly if needed
- Technical Team: Twice weekly and ad hoc as needed. Open technical forum and open items, 2-week look-ahead. Located physically separate from production engineering function
|
| Skills and Functions |
- Core Team: Executive sponsor, product engineering, voice of customer, innovation management
- Core Team: Intellectual property (to endure freedom-to-operate), business development (partnering), testing standards
- Technical Team: Multiple science disciplines, outsourced engineering
|
| Process and Timing |
| Risk Assessment |
- First risk assessment during planning stage, identifying likely areas of greatest risk even in the face of a high degree of uncertainty
- High level critical path with Level 1 milestones and proforma buffer zones
- Critical path and risks communicated to stakeholders, stressing fluid nature
- Continuous assessment of risks throughout the program
- * Escalation to steering team as needed and quick decision-making
|
| Flexible Oobeya Methodology |
- Hard copy visualization of program plan on short- and long-term time scales in physical team workspace
- Selective enforcement of critical path
|
| Knowledge Transfer |
Multi-layered meeting cadence for geographically disbursed team
- Virtual interactions and site visits
- Structured and open-ended discussions
|
| Tools |
| Collaboration |
- Reach across enterprise boundaries
- Fast, painless and inexpensive to set up
- No user training required
- No separate budget allocation required
- Example: Box.com, Dropbox, Basecamp
|
| Development Infrastructure |
- Adopt best-of-breed tools based on specialized external expertise
- Build-out of development infrastructure
|
Deriving Value in Innovation Management
The ideal scenario for a production-focused program manager is to be able to plan so successfully that any changes needed during the course of the program can be kept to an absolute minimum. With an innovation program, however, the value at least partially comes from the journey itself, and the lessons learned along the way - not just the end product. On the battery project, most of the value was derived before the team delivered the actual prototypes. A true innovation program must allow for flexibility; so changing the program plan is unavoidable.
Best Practices
Many of the -practices deployed in this engagement could be successfully applied on many other kinds of innovation programs:
- Isolating the innovation team from the pressures of product engineering, to prevent following legacy customer requirements.
- Including adequate voice-of-customer representation on the steering team to keep the innovation team informed about overall market demands.
- Adding two vital functions to the core team: intellectual property (IP) to ensure freedom-to-operate; and business development to identify possible partnering opportunities.
- Continuously reassessing risk and redrawing the critical path. The program manager and technical lead were in constant dialog about when to insist on process and milestone discipline and when to let the innovation team run with ideas. The result needs to be seen as a constantly swinging pendulum.
- Creating a powerful steering team designed to make decisions quickly and eliminate roadblocks - setting the expectation that it would be run as a decision-making body, not as a status update committee.
- Compartmentalizing crucial functions (such as voice of customer, IP, business development) between the steering and core teams. Decisions were based on set expectations we had for different stakeholders as to their contribution to the progress of the program.
Deadlines are a business necessity, however, and the battery project had a very definite one - December 2012. On the day of the tech review the President of the Business Group will be able to test drive two prototype cars as a proof of concept.
Successful innovation program management means we have achieved in six months what a manufacturer would typically take two years to accomplish. We have walked a fine line between giving the researchers scope to explore - while keeping focused on the end goal. It has been a fascinating process, and the tactics we employed to achieve our goal in a quarter of the time are tried and tested techniques - and most crucially, developed a mindset that can be used to drive other R&D programs on to future success.
For further information on this article and Pcubed please contact Linda Lavine, Director of Marketing, at linda.lavine@pcubed.com.
Stefan Stuerwald is a senior principal consultant at Pcubed focusing on innovation and new product development. Contact Stefan at stefan.stuerwald@pcubed.com.