There's a lot of give and take when it comes to setting up a change process, and a lot of factors that determine if your process should be highly formalized, or loosely managed.
A loose change process, where individual engineers have the discretion to either expedite change requests or make immediate revisions, exposes your product to unintended consequences - - including costly scrap and rework at best and field failures at worst. But excessive review slows down the iterative process and burdens team members, making it harder to innovate and rapidly improve product quality.
When thinking about your own change process, here are some things to consider:
If you're early in the product lifecycle and had a small engineering team, the details of the design will be very familiar to everyone and a looser change process might work for you.
If your manufacturing process is vertically integrated (meaning you can generally go downstairs and see the result of a change immediately) a loose process might work for you.
However, if you are a large company producing higher-volume products, it’s important to follow a formal change process in order to minimize the chance of decisions with unforeseen implications.
Or if you have several engineering teams in different disciplines, and there are a lot of opportunities for one change to impact another aspect of the product, you might want a more formalized change process.
Arena CTO Eric Larkin shared his experiences running 2 companies - - one with a formal change process, one with an informal change process. He talks pros/cons here.
One thing that he said stood out in particular to me - -
"I also recommend that companies experiment with a less formal review of changes in the design phase and switch to a tighter approval process in production—when mistakes can have major repercussions. And no matter how changes are handled, product data needs to be centralized."
Does anyone else have experience, thoughts on this subject?