Everyone has something they would like to see different, some aspect of the development process that they view is causing continuous disruption in new product releases. Reflect on your businesses ability to react to near term project execution crisis. Like most, the ability to resolve an immediate roadblock that is impacting a specific project is quite impressive. The team rallies to action in a high-energy fashion, makes a decision and moves on to a solution very quickly.
Now consider an issue that is systemic in nature, in that it’s omnipresent and has the ability to disrupt a wide range of projects. How’s the energy for resolution in this situation? I am sure it lacks the vigor that is observed for a project specific emergency. The persistent systemic execution barriers routinely take a back seat to the highly visible, project specific issues that crop up and block a project. Interestingly, the more pervasive problems are generally much more of an execution hindrance than the high intensity, bang on the table and fix it now project glitches that demand immediate solutions.
There is an interesting dynamic going on between these two different scenarios. In the case of a project specific problem, the team only needs a specific one-time solution to a highly visible problem; a perceived permanent operational change is not expected. For systemic execution problems the issues tend to be insidious and behind the scenes, often not displaying an obvious specific project related fire to be put out. Operational change is assumed to be the solution in this situation.
A new product team rallies to high profile fires very well, a concept that could be leveraged to deal with the more pervasive issues; the ones that are subtly, although more significantly impacting project execution. Does that mean solutions to the systemic issues are as close as setting them ablaze, thereby attaining much needed attention? That’s partially true with one very important caveat to consider. Solutions to systemic execution blockages will also involve “changes” in core processes and procedures, something that is rare in dealing with project specific issues. Individuals generally repel change, unless the change is elsewhere and will not directly impact them. Where are you and your organization with respect to seeking, owning and accepting real change?
Here is the most important concept when dealing with change. Most individuals will internally believe in the statement “I want things to be different, but I don’t want to change.” This is a stark reality that must be considered and mitigated. Once the realization of a potential personal change takes place, individuals will pull back and solution energy will fade. This fact leaves most organizations trapped in a mode of “tweaking” their new product development process, with results that provide unimpressive incremental improvements.
Where dramatic improvement to new product time to revenue is an expectation, real change is the only enabler that will produce this level of results. This is possible only when organizations stop fooling themselves that they can “tweak” their way to significantly better new product revenue and begin a grass roots assault on the “historic” ways of doing things. Anything less is a smoke screen to protect individuals while placing the organization at risk of a slide towards extinction. Terminal sameness can be successfully reversed, if properly diagnosed and treated in time.
Tuesday, April 13, 2010
I want things to be Different, but I don’t want to Change
Posted by Jeff Jorvig - IC Design Leader at 9:46 AM
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment