Change Management Process(es) 1

[joshua0977]

Change Management processes can consume a lot of time to get through a change / review cycle. We have 2 Release processes in our company.
a) Engineering Release for Dev/Limited Product
b) Product Release for pure production.
We struggle with the serial-ness of the processes and I'm wondering... what types of processes/automation/change management processes other organizations
use. Is yours robust or does it have a lot of latency in the process(es). What does your process look like?
Thanks Josh

 

[truckandbus]

My current company tries to utilze the series/production release process to manage development programs - this has been a disaster on many fronts.
1) departments downstream of engineering concentrate on series/production ahead of development, so schedules slip in development
2) departments downstream of engineering utilize their standard procedures when handling development programs, so time is wasted doing things like getting quotes from multiple vendors and negotiating pricing on immature designs, running FAIs, developing manufactuting routings, etc.
3) high risk of development bills of material making their way into production

The arguements for doing this are: independent system takes time and money to develop; all departments would need training; increased workload on engineering to transfer the design from development status to production status.

My previous company had the approach to have dedicated individuals from downstream departments working on development; we manually manipulated bills of material for development builds (to isolate the production bills), utilized small R and D shops to produce and QA prototype parts (also allowing for alternate materials and processes to produce them in order to proof concepts) and we sucked up the fact that we would need to invest time in making a final production release. Personally, I think this worked better but there are some problem areas that need to be considered
1) transfer of knowledge from the dedicated development staff to the series/production staff and
2) sufficent discussion with series/production vendors and manufacturing personnel so that design revisions are not required to accomodate supposed 'optimizations' for their processes

Hope this helps.

 

[ptruitt]

Without respect to where I presently work, I would say that, if possible, a competent team of people from various areas of responsibility in the company who have had experience at various capable companies should lead. But younger folks or folks with less experience must be fully engaged to keep the company viable. I would put that requirement ahead of processes. Not that processes and methods are not important. Where I work, I think that Marketing should rank the various products with respect to the impact/visibility that they have on the Brand. Inexpensive products that loose their association with the Brand as soon as they are removed from the package should not have the same development steps that other products with important Brand-recognition features have. Risk (broadly) must also tune the processes and methods employed. The risk should, in some appropriate manner, be formally quantified early. Before the development begins, Brand-visibility and risk ranking should help the group to decide which of the fomally-defined development processes is appropriate for that specific project.

Peter Truitt
Minnesota