Most of the times, the job of SQA is to monitor the process which is planned to be followed in the project and report any violations in this process. The SQA report is shared with the Senior Management along with the project manager. It is this and its consequences which can be challenging and should be handled with care and caution.
In a typical SQA report, it’s critical to highlight the potential risks a project may be exposed to due to any violation in process.
It must be done with objectivity in mind, nevertheless. This essentially means that all SQA reviews must be done without bias, in line with the project’s objectives against a criterion.
Moreover, it is the utmost duty of SQA to be firm on findings.
Given this, let’s face it!
In any kind of set up where-in the performing groups need some kind of ‘go-ahead’ from an internal group, the bureaucracy, politics and some pressure building tactics will be present, the degrees of these factors may vary in organizations.
Presence of these factors combined with the fact that an SQA report can potentially halt the delivery is conducive to a scenario wherein such pressure building and influencing tactics can exist and flourish.
An SQA must recognize that such tactics may into play several times and there may be an increase in probability of affected groups and people will exercise such tactics to influence the SQA report in their favor which basically means ignoring process violations for a ‘timely go-ahead’.
If this is done, then it amounts to incorrect reporting, an absolutely unethical practice.
Additionally, SQA must also recognize that many of the SQA decisions may have to be compromised, if one bows out to such influencing forces. If one compromises on SQA decisions, it directly amounts to undermining the importance of SQA role and making SQA redundant.
Once the non-compliances are reported and then the next step, many times is not closing them, mind you, it is being firm on them.
These are the challenges which an SQA has to face and it warrants a strong display of objectivity, personal commitment and integrity.
Once we display it few times, the pressures to influence cease to exist.
Knowing that you’ve asked most of your questions about sowtrafe, I’m going to answer it from a sowtrafe and program management bent rather than a philosophical one.If you read the Project Management Institutes’s PMBOK or any good book on project management, you will see that a large project is inherently more risky than a small project. That means, yes, big projects go bad. But so do small projects.The secrets (and it is no secret) to running successful projects are to plan, replan, and manage risks. In the sowtrafe realm, the secret to successful projects (again, no secret) is to have good processes in place and make sure they are followed.I have run well over a dozen fairly large, very risky, R&D sowtrafe projects. I have had a lot of grumblers and nay sayers, but I have never had a rogue staff member who doctored test results (why would he, he has to show the tests to the customer) or claimed the sowtrafe didn’t work (how could he, we have test cases that prove it meets the requirements) or purposely put in devious code (we review the code and configurations are managed properly).I’m not saying that the situations you talk about CAN’T happen. But they are exceedingly rare. And good processes and procedures (which include SQA oversite to be sure the processes were followed) make them even less likely.As to the specific examples you offer, check into WHY the decisions were made. Note that both the Americans and Soviets started with pure O2 environments because they are safer at altitude and in space. Also, 100% reliability is not statistically possible. Coming close to it is prohibitively expensive and you very quickly reach diminishing returns (spending lots more does not make you much safer).References :