Hi Jeff, nice blog!
I have a question about PPQA and PPQA of PPQA (GP2.9): how to implement these practices without creating a burden or overhead to the organization? I mean: how to make this group add value to the company instead of being the “pain in the a#$ group?"
Hey thanks! It's always nice when the readers don't hate the blog! Also, this is the first post I've had to censor for language. Fun stuff!
What a great question this is! You must have heard that PPQA stands for "Process Police and Quality A#$###*&. Well, contrary to popular myth this isn't really what PPQA is for. So let's start with my definition.
PPQA, or Process and Product Quality Assurance (and GP2.9 of any process area) exist to HELP us. How about that! It's like the old fashioned police whose job was "to protect and serve" but somehow has morphed into "profile and pull over." Of course, just like the real police, PPQA is so much more than what is percieved and joked about.
How did this metamorphasis happen? Well, let's go back to the beginning. Why do we even need PPQA? We need it to ensure that what we rolled out as a process is actually working, is helping projects, and is having a positive effect on the business. In order to do that, it must be determined whether or not people are even using the process to begin with. And that's where too many PPQA teams stop! They struggle so much with the compliance piece (mostly because people are not using it) that they're exhausted and never move on the the more important "providing insight" piece.
Providing insight back to the process owners (and SEPG) is the best way for us to learn whether we did a good job rolling out the process.
Whoa! Hold on a minute.
What was that you say? You mean we didn't do a perfect job designing and rolling out the process and now some PPQA puke wants to tell me something I already know! Darn PPQA zealots!
When I hear an executive or engineering manager whining about how people aren't following "my" process, my tingly senses start going off. So I tell them . . "hmm, guess you kind of screwed up on rolling out the process, eh bub?"
You see, if we did a great job designing the process, communicating the process, and educating about the process, people would probably use it. If we over-engineered it, designed it poorly, announced it with an email, and said "go forth and be process focused," then we did a poor job.
And only PPQA can tell us that.
So, start with a re-definition of PPQA's role. It's to provide independant insight back to the process owners as to how well the process is working. This is a direct reflection on the process owners and their ability to roll out processes effectivley. The SEI wisely realized that we drink our own kool-aid, the that can cloud our judgement.
Say that, and the project teams will look at you in a whole different way. Good luck!
http://www.broadswordsolutions.com/
3 comments:
To add to what has already been told - this PPQA actually helps the associates of the Org to learn and implement the same in their projects also.
In the Org where I work, we have associates (who have minimum of 5 yrs of software exp) are made part of the SQA auditors (part time). Their role is to be part of the project and also conduct SQA audit for other projects. A full time SQA Manager plans the activites and the training.
A SQA Induction training prog is held (a day training) where most of the basics of Quality, process is discussed/trained. Over time the auditors learn the importance of process and also implement the same in the projects that they are working.
Initially it might look like over head for the auditors but if you think deep the "process" understanding is nothing other that what they really do in their own projects.
Thanks
Chandrakant
Make sure your PPQA personnel get good auditor training. ASQ Quality Auditing Certification might be helpful.
Also, although the Sensor was a *&!@!! fine razor, I think you meant censor.
I never looked at PPQA this way before
Post a Comment