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?