Caution: Innovation in Progress

One of the biggest advantages of incentive prizes like those we run here at the X PRIZE Foundation is that they allow an enormous amount of parallel innovation. In most traditional forms of research and development, the innovating body--the lab, the scientist, the company, the agency, the manager, whatever--has to perform some trade studies and down-select to a small number of research avenues they determine to be the most likely avenues to yield the desired results. That's by no means a mistake--that's sound management and efficient allocation of resources. But often, those decisions end up ruling out potential avenues that may in fact have the highest yield--because they also carry the highest risk of failure. By contrast, when an incentive prize is offered, an entire 'innovation ecosystem' is set up, wherein a much larger group of those research avenues will be pursued by one or multiple competing teams. In this fashion, a lot of theory can be tested in practice, and the entire industry can learn lessons not only from the eventual winners of the prize, but from all of the competing teams.

Now I, for one, tend to think about technical innovation as a general rule whenever I'm thinking about the phenomenon of parallel innovation as a specific benefit of prizes. But in reality, that's a mistake on my part. There is plenty of room for innovation, and it is by no means limited to the technical. Our teams are innovating and will continue to innovate not only with their technical systems, but also with their business plans, their mission operations, and even with their management structures.

With an increasing number of our teams incorporating open source ideals into their core philosophy, that will increase the opportunities for learning from these multiple parallel innovation avenues even further. A case in point is with our Google Lunar X PRIZE team FREDNET. Now, I'm not an expert in management theory, so perhaps this has already been tried out on a similar scale, but I for one was very eager to see how FREDNET's Open Source Management of an Open Source Hardware project would work out. I'm well aware of the success of open source software, but how would it translate? How would they organize it? How would they reach their goals?

And FREDNET and a lot of our other Open Source (or Open Sourcey) teams, bless their hearts, are letting us watch along. We get to view the process, warts and all. I try to keep tabs on all the teams, obviously, but online tools like FREDNET's forum make it particularly easy, and provides a level of insight the general public simply can't get into many teams.

One thread I found particularly interesting on the FREDNET forum is an ongoing one titled, simply, "Are We Close?" In that thread, you can read along as the boundaries and limitations--and the advantages--of the open source managment style are probed. Team members ask genuine and important questions about their own team and about its structure. These questions are considered and answered. Certain unavoidable weakness are identified and analyzed against the advantages.

It's way too early for us--or, for that matter--the members of FREDNET to say how successful their team and their effort will be. But it's already clear to me that we're learning a lot along the way, something we likely wouldn't learn if we, or Google, or anyone else had simply funded one team to perform a mission to the Moon. Parallel innovation at work--and that is a very good thing!

Anonymous said...

You are right on spot :-)
It's worth noting that our organization has changed a few times since the beginning. Not because the team management wanted it to change, it just happened by itself. We could have prevented it, but we chose to let it happen and see where it leads. I'm sure it will keep on changing as we move through the phases of the project. We try, we progress, we stumble, we get up and go on ...

blog comments powered by Disqus