Home » Change Management » Being Chaotic Is Often Smart In Project Managing Innovation

Curtis Carlson, CEO of California-based research institute SRI international, argues that the future lies with companies that encourage their lower-level employees to be critical thinkers. “More and more,” Carlson says, “innovation that happens from the top down tends to be orderly and dumb. Innovation that happens from the bottom up tends to be chaotic but smart.” America the Pitiful, Bloomberg Businessweek, Oct 3 — Oct 9th 2011.

I’m a great advocate of bottom up innovation. My personal and professional experience is that just about all the great ideas generally came out of folks doing their everyday jobs and living their everyday life. I’ve seen dozens of downward directed “improvement” efforts in government and industry and I can’t recall a single one that made a difference — unless somewhere deep in the organization an individual or small team adopted it and made it their own. In some cases, where a team started to run with an innovation I’ve even seen the “official implementation team” attempt to discourage or block those teams from taking their own initiatives!

Being Chaotic Is Often Smart In Project Managing InnovationOnce when I was arguing with a Director of Quality on how best to implement an initiative in my project, he responded by listing all his certifications and training (CMMI, Six Sigma, ISO, PMP, etc.). He then suggested that he knew how everything should be done and we had to do it his way because of all those pieces of paper. His effort had no obvious effect while our initiative to finally deliver a huge project on time succeeded. He was implementing improvement initiatives as his job (hence all those certifications qualified him for his position) and we were just trying to do a project (to produce a product) and we were innovating as needed. We were in fact trying to support his effort and leverage it to our advantage, but he wasn’t interested in our ideas, only in doing it “his way” which was ultimately counterproductive and out of touch with a real ongoing project.

A lot of initiatives are often great ideas and things that we could benefit from by doing. Top down driven innovations and changes, however, often lose touch with the reality of the workplace. The trick, in my experience, has always been to engage and empower folks and not to assign experts and project managers to “impose” the changes on them. Worse yet, I’ve concluded, is to make improvement and innovation a separate job description or career field. All this may appear at first to be a chaotic and unmanaged approach to innovation, but the successful results speak for themselves.

What examples of successful bottom up or top down innovations you have personally experienced?

Thank you for sharing!

2 thoughts on “Being Chaotic Is Often Smart In Project Managing Innovation

  1. Jean Richardson says:

    This seems more like a rant than a description of bottom up innovation. So, can you say more about:

    — What your team’s process improvement actually was?
    — What the effect was?
    — How you defined “success” or identified that it had occurred?
    — The organization’s definition of “success” if it differed from the team’s definition?

    1. Bruce Benson says:


      Just about all my examples are bottom up successes, here are a few:
      1. It should work the first time: http://pmtoolsthatwork.com/it-should-work-the-first-time/
      2. Test every line of code: http://pmtoolsthatwork.com/key-step-successful-improvements/
      3. The leap to success is shorter than we think: http://pmtoolsthatwork.com/leap-to-exceptional-shorter-than-we-think/
      4. Get the schedule right: http://pmtoolsthatwork.com/get-schedule-right/

      The primary effect and definition of success was generally (differs a bit depending up the case):
      1. Project delivered on time, usually for the first time anyone in the organization could remember and where it was normal to deliver 3-4 months late.
      2. Project quality (product, defects, returns) was clearly better than the past, even to the point of scaring the wits out of test/quality organizations who felt their jobs were threatened (http://pmtoolsthatwork.com/stress-your-test-team-give-them-quality/)

      In just about all these cases theses organizations had reached a point where delivering projects late and buggy was normal. It was just “well understood” that delivering on time was more a noble goal than something that we could really do on a consistent basis (or even … ever). So “success” was pretty mushy, but usually centered around if we were still in business or not.

      Hope this helps.


Comments are closed.