Innovation: a bunch of posts that I appreciated

Innovation for the Long Term (Three Horizons model)

3 Horizons:

• Horizon 1: Extend and defend core businesses
• Horizon 2: Build emerging businesses
• Horizon 3: Create viable options
  

How this could apply to Google for instance:

• Horizon 1: Extend and defend core businesses
• web search, adwords, gmail...
  
• Horizon 2: Build emerging businesses
• google docs, cloud computing...
  
• Horizon 3: Create viable options
• Solar Panel Project
• Google Improving Mirror Technology For Making Solar Concentrators 2x Cheaper
• ...
  

5 Questions That Kill Innovation: A How-to Guide

• How can we leverage our core competencies to tackle this new market?
• How much money can we make and whats the plan to make it?
• Have you done enough research on the idea and do you need more money to make it happen?
• Who else is doing this, and if no one is, why?
• How big is the market and will consumers want this solution?

Innovators and followers: who wins? What does it take to be a successful follower?

• observe
• build something somewhat different
• experiment and learn faster

 

Using rivalry to spur innovation

Less in line with mainstream R&D practices: the degree to which Renaissance creativity was built on professional rivalries—like the ones between Leonardo, Michelangelo, Raphael, and Titian—that are commonly viewed as some of the most productive in history. It may be that by overlooking the potential of rivalry, modern R&D organizations are missing an opportunity to promote ground-breaking innovation.

Future of Requirement Management Tools

I've been looking at Requirement Management tools for 5 years now.

Requirement Management tools are all evolving towards a common view. They now offer the same kind of functionalities, in a similar way.

For instance, a few years ago, for most of the tools, the way to present requirements was only available as a list of requirements title. To look at the requirements details, you had to click on the specific requirement.
Now most of them, are offering a "word document view", where requirements can be displayed as a word document with chapters.

In the future, my feeling, is that what will be important is, not the functionalities offered by the tool itself, but the level of integration with test management, change/bug management and code source file management tools.

One of the main functionality of a Requirement Management tool is traceability. Traceability between marketing and technical requirements and specifications. This is today handled correctly by most RM tools, but an advantage comes when you can also link requirements with tests and build some test coverage tools for instance.

And we can go further by extending tracceability to changes/bugs and even source file.

Here is a view that summarizes my point:

One of CMMI Requirement Management specific practice says: ["SP 1.4 Maintain Bidirectional Traceability of Requirements" - Maintain bidirectional traceability among the requirements and work products.].
Using closely linked/integrated test management, change/bug management and code source file management tools is an "easy" way to achieve this goal.