John BaconProject Manager /Agile Product Owner| Not DisclosedFl, United States
I'm trying to write a quality management plan for a software development project and I'm a little confused as the neither the PMBOK or my IT Project Management textbook really clarify how The key components of project quality management which are Quality Standards, Quality Assurance and Quality Control would be documented in a plan.
I understand that quality assurance is PROCESS focused and quality control is PRODUCT focused.
So when it comes to an IT software development project, what would I outline as quality standards? Would this be like adhering to the PMBOK project management processes and ISO standard that defines the software lifecycle processes?
As far as quality assurance, this section of the plan I guess would outline how the processes will be monitored for quality?
For quality control, this would be focused around TESTING I guess? For example testing project deliverables to ensure they meet the specified requirements.
I welcome any feedback on how Quality Management documented in a plan applies to a software development project. Saving Changes...
All the X management plans basically cover how that knowledge area would be addressed on your project.
You might want to take a look at the DA toolkit and its process goals related to quality. If you and your team make decisions related to those goals, those decisions and the rationale supporting them would be captured in a QM plan.
You will want to define specific objectives or targets for quality, and then define the metrics aligned with those and practices which will support those for QC and QA.
QC would usually go well beyond testing if you are shifting quality left. TDD, pair programming, code reviews, requirements traceability and other practices are all QC related.
Talk to your teams and their managers (BAs, if you have them, developers, QA testers...) about how they manage quality. The last time I documented a formal quality plan, nobody read it. Now, instead, I capture what is done, make sure everyone agrees that is how it's done, and then keep them accountable. I don't have to create a new document for each project because the practices are part of what is expected from the team members whether, or not, they are on a project.
When there is a problem with quality, we can review whether their processes were followed, and then respond accordingly.
The only significant variation I've seen, so far (and 'significant' may be a stretch) is the difference in the level of issues a project can launch with that will be fixed post-launch, but that was primarily due to time constraints and launching would add more value than the defects would take away. Saving Changes...
Community Champion
