One Good Use of Product Development Standardization
I spoke to a gentleman yesterday who worked in a corporate office charged with aligning the various engineering teams within a large company that had grown by acquiring a couple of dozen smaller companies, all producing similar products. The company hopes to realize synergies by developing comprehensive solutions that draw products from multiple subsidiaries. However, most of the companies were founded by entrepreneurs, had home-grown processes at best, and could barely communicate about the basics of product development, much less actually collaborate on a new product.
This is an example where a high level, lean stage gate process makes a lot of sense. It's nearly impossible to avoid the waste of reinvention in such a setting. A standardized, high level framework for product development helps by creating a common vocabulary and structure. When I call and say that I'm working towards my first proto tooling release and could use a little of your expertise from the product you just released, you know what I mean.
The risk is that such a process will lead to bureaucracy. In a large company, the temptation is strong to add in everyone's pet action item and report, causing the lifecycle to eventually collaspe under its own weight. However, it seems that this company has avoided such pitfalls.
The teams have the ability to improvise within this framework to create a product development process that balances the needs of the corporate parent with the needs of the specific product's customer. They are not overburdened with proscribed administrative reports and checklists to complete. Teams are not arbitrarily required to batch their work until after they pass a specific milestone, causing reinvention and time-to-market to increase.
How does your standard product development process balance structure and flexibility?
This is an example where a high level, lean stage gate process makes a lot of sense. It's nearly impossible to avoid the waste of reinvention in such a setting. A standardized, high level framework for product development helps by creating a common vocabulary and structure. When I call and say that I'm working towards my first proto tooling release and could use a little of your expertise from the product you just released, you know what I mean.
The risk is that such a process will lead to bureaucracy. In a large company, the temptation is strong to add in everyone's pet action item and report, causing the lifecycle to eventually collaspe under its own weight. However, it seems that this company has avoided such pitfalls.
The teams have the ability to improvise within this framework to create a product development process that balances the needs of the corporate parent with the needs of the specific product's customer. They are not overburdened with proscribed administrative reports and checklists to complete. Teams are not arbitrarily required to batch their work until after they pass a specific milestone, causing reinvention and time-to-market to increase.
How does your standard product development process balance structure and flexibility?
Labels: process
0 Comments:
Post a Comment
<< Home