The original version of this article can be seen at the Capgemini – Capping IT Off blog.
The wheel was invented mid 4th millennium BCE. The first car appeared in 1335… historically innovation came at a slow pace because of the time it took to turn ideas into reality.
This meant the new products had time to be tested, gain acceptance and be put into service for many years to come before evolving to the next big thing.
But the speed of innovation went into light speed with The Dawn of The Internet. Suddenly finding the right people with the right knowledge as well as buying the right tools can be done at the speed of a mouse button click… and that is for traditional ideas.
The problem escalates with digital ideas as they not only thrive on the speed of the Internet they also lack of physical restrictions imposed on ‘real-life’ ideas. Digital ideas can be started at the blink of an eye with the only real restriction being budget and this can be fatal to a project.
Example: An idea currently in development is stopped and replaced by an even better idea which then gets developed. Some time is lost, but since the product is digital no physical stock is lost nor has any purchased component/ingredient been made redundant…
…but time is lost.
And with multiple ideas evolving in this manner the project starts rolling on and on and actual completion seems to be further and further away. And time triggers new ideas that may make the second generation of ideas redundant as well.
Other completed functions are left waiting for the new innovations to be developed into complete functions as well. This can be fatal for these functions as innovations outside the project may deliver something similar or better and suddenly the advantage of being first to market is lost… Not to mention these external (and live) innovations may trigger new ideas that could replace these now redundant digital functions.
The product may be getting better but it is never delivered; it never goes live and it never becomes real.
So how to stop the innovation ravine? The answer is quite simply; define purpose with measurable goals up front and stick to it. As soon as an idea fits the purpose and meets the goals, stop the ideas and proceed into development and deployment.
Get it done. Get it live.
Any good ideas that appear after the “idea stop” should be captured but not actioned until the purpose box has been ticked as fully functional and the product is made live.
There is something for the users to use now. They are no longer held in suspense waiting for the project to deliver what they need. And now it’s time to look at the stored box of ideas and use them to add new functionality and new upgrades to the system.
But the best part is that real users are using the product for real and can provide real feedback to help trigger even better ideas than the box of ideas that appeared in isolation during the project.