“The overall success rate of innovation initiatives in business is around 4%.  Yet many businesses report they have too many ideas and waste precious time and resources struggling to select the ones most likely to succeed and then work them through to adoption.  We are idea rich, selection baffled, and adoption poor.” Peter J. Denning, The Idea Idea, Communications of the ACM, March 2012.

I’ve seen initiatives in Six Sigma, Quality, Process Improvement, Project Management, Software Design, Metrics, Agile, and many, many more.  Most of them did not work out very well.  These were almost all “formally selected and approved” initiatives that were then downward directed and were to “fix” the problems plaguing the organization (productivity, speed, quality, speed, cost, did I say speed? etc.).

The trick I found, as a manager,  was to instead cherry pick the various company initiatives that were going on and leverage them to get whatever idea I had at the time into practice.  Usually, it was about doing something that would help me or my team get the project done faster and more accurately.

“Many innovations clearly start as practices.  Someone starts doing something differently, often as an improvisation.  When the new way is superior to the old, others imitate it; the practice spreads.  After a while, someone builds tools to facilitate the practice and enable even more people to engage with it.” Peter J. Denning, The Idea Idea, Communications of the ACM, March 2012.

We were working with mainframe computers and doing assembly level programming.  The turnaround time for the mainframe was in terms of hours.  So if I made a change and wanted to see if it works, it could be hours before I could see my results.  It was always a struggle between only entering a few changes to see if they work or entering lots of changes hoping to get more done but possibly losing those hours because of a dumb syntax error that is inevitable with lots of changes that prevents it from running after waiting hours for its turn to run.

At the same time, the PC was just showing up in more offices.  It was being used to replace typewriters, ledgers, pencil, and paper (e.g., using word processing and spreadsheets).  Someone, another wonderful innovator, had written an emulator that would run mainframe assembler on a PC (this was an IBM BAL emulator).  I wondered if I could at least test out my code maybe just syntax check it on the PC?

I spent a long weekend around the clock typing significant portions of our mainframe system into the PC mainframe assembler emulator.  I had to create a lot of “stubs” to handle functions that the mainframe normally provided, but after a few twenty hour coding sessions (or so it seemed) I had something that actually ran our mainframe code, on a PC!

In the months to come, it took me almost no time at all to make changes to our mainframe system.  I could quickly design and code the change, check it on the emulator, and then submit it to be run on the mainframe.  The mainframe submission became nothing more than the final test and then I’d submit the code to be officially tested and go live on the system.  The test manager would tell me that testing my code was like testing a “rock.”  It just worked and there were never any surprises.

The rest of the organization didn’t adopt what I was doing, because … I didn’t tell them how I was doing it.  Why not?  Because it had not been formally approved to use our new PCs for supporting work on the mainframes.  It was a violation of the security policy to mix the two technologies.  Developing mainframe code on a PC would be seen as an unacceptable risk as PCs “were known” to be overrun by viruses.

So while it was a great idea, it didn’t get into widespread use because the rules that existed kept me from being willing to share it. Sure, it made me look good, but it sure didn’t help the organization to improve in the long run.

Most of the innovative organizations I worked in, innovated from the ground up, rather than from top down submitted, selected and directed initiatives. Those organizations that were the worst at innovating usually had many elaborate rules that made it difficult to impossible to innovate and often constantly told people that what they were doing was not allowed. Our teams and organizations inevitably have a lot of innovative potential, but it was up to us to find ways to uninhibit all that creativity and allow more good ideas to be developed and adopted.

What are you doing to encourage innovation within your project team?