During a quality assurance review, the QA director literally tried to take over management of the project by telling the teams how they should develop the product. He started to direct specific actions and expected status reports and the like back to him and not through the project manager. This was all done under the guise of quality assurance. It became simply “project management.”

Two things stood out in this experience. One was that this project would, upon completion, receive recognition and awards for quality (including from the customer). QA trying to “take charge” was obviously not appropriate as the team was doing a great job. Secondly, QA had no objective way to actually determine the quality of the project. I found this is often typical in organizations that struggle with getting projects done on time. QA is implemented more as a “shadow” second-guessing project management team than as a true QA team.

See related: The Worst Test Team

One has to acknowledge that in this particular example, up until the current projects, just about all our products were late and buggy. QA just assumed that this one would be the same. However, they had no reliable metric or measure to notice that something different was going on. Even the fact that this product passed its first major quality milestone on the first try and with flying colors (which had never happened before except by its immediate predecessor) did not seem to influence QA’s desire to take charge of the project and demonstrate their value.

Compare with: Are We Managing Or Are We Theorizing? Why We Need Real Metrics

From my experience, QA should maintain an independent and objective measure of process and product quality. Note the emphasis on “measure” and “process.” The most effective QAs I’ve observed have been data instrumentation, collection, and analysis focused. These objective measures are then used by project and senior management to gauge how their efforts at achieving quality are progressing (i.e., are we following our processes and strategies that result in successful projects?).

I’ve often seen this happen, quality assurance, process improvement, or other teams attempting to manage struggling projects. I’ve never seen “putting QA in charge” succeed at fixing an organization’s or project’s problems. If we find QA effectively taking over or being put in charge of projects, then this is an indication that both QA and project management need to relearn and refocus on their respective management disciplines.

How is your quality assurance team doing?