I've always thought of process and innovation as the yin and yang of the enterprise. From Wikipedia: "Yin and yang is used to describe how polar or seemingly contrary forces are interconnected and interdependent in the natural world, and how they give rise to each other in turn." That's about right, I think. Yet many people seem to think innovation and process work against each other and don't see how they "give rise to each other in turn."
IT Business Edge VP Ken-Hardin wrote about the innovation vs. process argument back in September, launching his thoughts by citing a Harvard Business Review blog post by Susan Cramm in which she wondered why so many managers continue to ignore best practices. As Ken said, comments following Cramm's post mostly fell into two schools of thought: Leaders "suffer from hubris that makes them believe the mistakes of others can't happen to them" or they see best practices as "a sure way to suppress innovation (emphasis mine) and commoditize your brand into ho-humness."
The innovation vs. process argument is a longstanding one in the technology industry. Many folks use Apple as an example of a company that prizes the former while somehow circumventing the latter. Not so, wrote Ken:
I've never seen any real evidence that Apple engineers are at liberty to just bypass key points of QA in the name of "innovation," or that the company as a whole disparages process when it comes to executing. In fact, in surfing some older content over lunch, I came across this interesting post that points out the obvious: Apple's four pillars of innovation (users first!) can't really be described as all that innovative -- nothing with enough cultural traction to be described as a "pillar" is innovative, at least not in real time.
After admitting that it might be oversimplifying the issue, Ken defined innovation as what you do and best practices as how you do it.
A similar viewpoint recently surfaced on the Back From Red blog. While project management consultant Todd Williams titles his post "Process Stifles Creativity," he doesn't say there is no place for process. He writes:
If you want open conversation, innovative thinking, and wild ideas, you drop the level of process and allow people to wander. People try new approaches, think outside the norm, and premier products and exemplary processes come into being. Yes, processes. Once we have a better way to do something we want to capture and implement that so others can use it. Therefore, I stick by my brash statement that process stifles creativity and let you conclude whether that is bad.
I agree that too much upfront emphasis on process can stifle creativity. Looking past existing processes at the beginning of a project is sometimes the only way to nurture ideas that might otherwise die on the vine because they don't fit the accepted best-practices mold. IT Business Edge blogger Rob Enderle wrote about a secret skunk works project at EMC, in which engineers developed a successful new product by "going around EMC processes, avoiding the typical internal politics that often result in a crippled offering."
But as both Ken and Williams note, processes must come into the mix at some point, to lay the foundation for future innovation. Chances are EMC already has or will adopt some of the practices used by its "secret" team, including the use of open source tools such as Bugzilla for software development and communications tools such as wikis to facilitate collaboration among geographically dispersed team members