IMPROVEMENT PLAN IN QUALITY ASSURANCE
- Thread starter elleeeeee
- Start date
Start with the customer.
How do your system’s services and products deliver confidence that their requirements are fully understood and fulfilled?
You may find the most important improvement opportunities are with the way your customers’ needs are understood and served.
Don’t stop at taking orders and delivery of the product but include marketing (determining future requirements) and invoicing with any reasons for tardy payment. Does your website inspire confidence? Note how you’ll be going well beyond the bounds of a QC focus (aka as Big Quality).
QA not only is the result of making customers confident their requirements will be fulfilled but it also imparts such confidence to your senior management who must also play their part.
How do your system’s services and products deliver confidence that their requirements are fully understood and fulfilled?
You may find the most important improvement opportunities are with the way your customers’ needs are understood and served.
Don’t stop at taking orders and delivery of the product but include marketing (determining future requirements) and invoicing with any reasons for tardy payment. Does your website inspire confidence? Note how you’ll be going well beyond the bounds of a QC focus (aka as Big Quality).
QA not only is the result of making customers confident their requirements will be fulfilled but it also imparts such confidence to your senior management who must also play their part.
In addition to John’s advice look at the quality basics: Think about what activities your QA group engages in. Do thy focus only on ‘police activities’ - catching people doing something wrong and tracking and nagging others to fix corrective actions or do they focus on helping people prevent and solve problems as equal or leading partners? Are they experts in problem solving? MSA? FMEA? Mistake proofing? SPC? DoE? Risk management? COPQ? Can they develop and track (with SPC) key indicators and objectives for the organization? Do they teach and coach these subjects? Do they craft and promote procedures and policies that guide their use? Can they assess teh organization’s strengths and weaknesses and provide practical improvements rather an nit-picky Corrective actions?
Another thought is how the systems that are universally managed by QA groups: are they set up to make things easier and still assure Quality Products for the user or for QA? An example is document control: how do you ensure justification, review and approval of the changes? Is there some electronic isolated signature loop or do you have a involved informed review panel? Howa re you assessing the risk of the change adn it’s unintended consequences? How are you documenting changes? Does it make it easy for the users to know what was changed - or do they have to read the entire document and guess at the change? How do you manage the communication of the change? Do the users just sign something so QA has a record or is there a positive communication (training) of the change? Another example that gets a lot of discussion here: do you assign an arbitrary timeframe for completing Corrective Actions or do you actively and knowledgeably track and monitor real progress and effectiveness?
I have some spare change from the North American holiday season, here are my $0.02.
A narrative caveat about what I wrote above. The lines between Assurance and Engineering can be blurry, for many reasons. Some quality groups are very small. Some organizations simply can't imagine that members of a quality group (no matter their title) could "know better" than whoever the recognized (or simply 'titled') subject matter expert. This is why it is important to not simply 'nit-pick'... each squeeze should produce juice. Some companies have "quality engineers" but the companies don't support (or understand) quality engineering.
My personal experiences have been that organizations typically stay in the immature states (levels 1 or 2 on the CMMI hierarchy) and if they never reach a true "Quantitatively Managed" state they will eventually backslide into one of the less mature states. My own view is that Quality Assurance is necessary to stay in a Managed or Defined state, but Quality Engineering is needed to get Quantitatively Managed or Optimizing state (levels 4, 5). I find it more rewarding to work towards the higher level of organizational maturity; if an organization offers such a path I would encourage anyone frustrated with a role designed to steady-state at a lower level to advance upwards in their career.
If the company really has a different set of functional responsibilities for Quality Assurance and Quality Engineering, my suspicion is that those strictly in the Assurance group are primarily going to be limited to "getting good/efficient at their duties". Working with the Engineering group on Quality Engineering is encouraged of course. If nothing else, the QA group could feed suggestions for process improvements to the QE team.... you may be assigned action items for Preventive Action efforts.
A narrative caveat about what I wrote above. The lines between Assurance and Engineering can be blurry, for many reasons. Some quality groups are very small. Some organizations simply can't imagine that members of a quality group (no matter their title) could "know better" than whoever the recognized (or simply 'titled') subject matter expert. This is why it is important to not simply 'nit-pick'... each squeeze should produce juice. Some companies have "quality engineers" but the companies don't support (or understand) quality engineering.
My personal experiences have been that organizations typically stay in the immature states (levels 1 or 2 on the CMMI hierarchy) and if they never reach a true "Quantitatively Managed" state they will eventually backslide into one of the less mature states. My own view is that Quality Assurance is necessary to stay in a Managed or Defined state, but Quality Engineering is needed to get Quantitatively Managed or Optimizing state (levels 4, 5). I find it more rewarding to work towards the higher level of organizational maturity; if an organization offers such a path I would encourage anyone frustrated with a role designed to steady-state at a lower level to advance upwards in their career.
Randy
Super Moderator
Yep, for starts quit getting all messed up with words, terms and designations of people. In the end a title doesn't resolve anything but performance meeting requirements/needs does. So whether one is an QA, QC, QE matters not one bit any more than in they were called ASE (Apple Spice Engineer), PSP (Pumpkin Spice Engineer) or CDW (Chief Dog Walker)...........Specifically define a role, responsibility, authority and accountability for everyone involved in whatever, call them what you want and go for it or you're going to continue in your present state.Currently I'm working at the company as a QA Engineer and it seem like the role is not dominant if compared to QC Engineer role. Is there any improvement that we can do to improve Quality Assurance rather than conducting audit. Thanks in advance
All valuable advices from our esteemed QA nerds. Just one more tiny point imho: You will see the added values/differences between QA and QC/Q Eng. clearer when an organization wants to reach the Level 5.
It's about (QA) Culture, and at this level you can expect to see the nucleotide "Q" in all staff's DNA (not only A, T, G, and C).
From 1 to 4, it's all about "managed", quantifiable and technically doable.
Happy New Year '2024 to all of you!
Last edited:
arpitadey15
On Holiday
Certainly! It's common for QA roles to be perceived differently than QC roles. To enhance the impact of Quality Assurance, consider implementing proactive measures like implementing robust test automation, fostering collaboration between development and QA teams, and continuously refining testing processes. Engaging in early involvement in the development lifecycle can elevate the QA Engineer's role beyond audits.
Similar threads
