In my opinion, good training up front can help people adapt more easily to changes in the way they do their work. The training needs to include a bit of a sales pitch to answer these questions:
1. How will changing the process help me do my job more efficiently?
2. How will this process help me deliver higher quality products?
3. What will I have to give up to adapt to this new process?
Once you get through the answers to these questions, then you can begin to present the changes to the QA processes. It's a lot harder than you would expect to get people to change, but once they start to follow a sound process, they will see the benefit.
By implementing QA processes slowly over time, using consensus to reach agreement on processes, focusing on processes that align tightly with organizational goals, and adjusting/experimenting/refactoring as an organization matures, productivity can be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, avoid a 'Process Police' mentality, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or bureaucracy, and in the short run things may slow down a bit. A typical scenario would be that more days of planning, reviews, and inspections will be needed, but less time will be required for late-night bug-fixing and handling of irate customers.