Occasionally, I hear the phrase, "We don't want to reinvent the wheel here." It's always used in reference to some pending effort where a project team must work to achieve a result, and someone senior wants the team to leverage an existing, but partial, solution. It's perceived to be a leg up, a jump start. The senior exec posits, "Why should we waste time and money when we don't need to?" It's a means toward getting it done faster, using "proven" methods and "best" practices. I'm here to tell you that the wheel should be reinvented. A lot. The one thing that always, without fail, bites a project in the ass and sets it behind schedule is the assumption. Somebody somewhere along the line made an inadequately informed assumption. Assumption: the methodology before us will allow us to meet the project's goals. Therefore, we should use that and build on top of it. But you know, unless you deeply understand the previous methodology (rare) and unless it's completely open to you to manipulate and change as required by the solution (also rare), there is no way that the methodology can give you a leg up. In fact, if anything, it gets in the way and requires workarounds. In other words, only in rare cases, in my experience, do you not need to reinvent the wheel. (Keep in mind that the "wheel," in my reference here, is not a tool or materials.) Innovation happens when we change it up. We mix, we adjust, we play. We do the unconventional. Innovation doesn't happen by doing it the way others did it. Innovation is reconsideration. It is new methods, new practices, new processes. Innovation happens when you reinvent the wheel. Look at some market examples: The iPod didn't borrow from previous MP3 players.
Google didn't try to do it like Yahoo.
Dell didn't make computers like others.
The Tesla doesn't run like other cars do. Yes, these are big, well-noted, game-changing products. "But our project is not trying to change the world." Fair enough. But shouldn't any idea worth implementing deserve the consideration of its own application without driving down the narrow straits of previous implementations? What if this needs to be different? Look different? Behave differently? Wouldn't that require, then, a different approach? Maybe the vehicle doesn't need wheels. Reinvent the wheel? Forget the wheel. Fly.
Swim.
Burrow. No wheels required. Might that be your project? Maybe. Have you stopped to consider that? In painting and in writing, I've learned that the best way to a great result is to wipe the slate clean and start over. The secret to great writing is rewriting. Re-painting forces you to re-learn the subject and leave your assumptions behind. It forces you to see things anew. Magic happens when you reinvent the wheel. ETC: This post was mistakenly titled "Rebuild the Wheel" and Rich, who I think knew what I meant to say, comments about the difference between rebuilding and reinventing. He makes a great point... he says: It seems most of the success stories follow this model - Bill Gates did not invent the computer; Henry Ford did not invent the Car... I think your post might point out the difference between innovation and invention.... Invention certainly takes innovation, but I don't think innovation always leads to invention. I think invention is the successful outcome of innovation, and not all innovation succeeds. And perhaps that's what senior execs try to avoid by using previous "best practice" methodlogy: time-wasting, money-wasting failure.What Henry Ford did invent, like Dell, was a new and improved process. Henry didn't invent the car. Michael didn't invent the computer. But their processes were innovative. (Bill Gates, in my opinion, is personally lousy at invention. Tim Paterson wrote DOS. Paul Allen finished hand-writing the BASIC interpretter that got him and Bill started while on the plane to Texas. He didn't write Windows. Visual Basic, the macro language that powered a generation of programmers and helped so many Windows apps, was fathered by Alan Cooper, a genius of design. What Bill did do very, very well was employ his aggressive opportunism, be it in fostering productive work environments or cementing deals with big companies.) Rich asks, "Should you be on the bleeding edge or just a fast follower?" I'm not sure innovation that leads to invention requires bleeding edge. Bleeding edge, in my experience, usually happens when a company tries to make use of a new methodology developed by someone else, and it's not quite a fit. Hence the blood loss... What I'm trying to advocate, and perhaps I didn't do it so clearly, is a hesitation to simply adopt what others have done before in the sometimes false assumption that it will work here too. By taking a bit of time to reconsider the problem and what would work best, reinvention might be the best route and deliver the most efficient result. (I've seen Rich himself do this successfully before, and I appreciate his illumination of my use of the wrong word.) What this approach requires is a deep trust in the design skills of the assembled team to get it right. Right innovation involves excellent design skills and a lot of attention paid to the end-user/audience. Once that's done, then the implementation can begin. The right design leads to obvious and successful implementation. | 
