As a project manager how much of software quality control you need to perform? Do you think it is important to focus from a PM perspective OR it is an architect role to take charge of the technical issues? Let us see.
Coordinating technical reviews can take care of software quality issues. A PM can act as a facilitator in arranging formal review process is followed for Design, Coding, Test cases and Testing phase. Capturing the data during each of the review stage will help gather important information regarding software development life cycle and help control the software quality assurance.
Review process can help reveal the effectiveness of the review, identifying defects in earlier stages of software development so as to control re-work and thereby cost. Adhering to the review process religiously can only be a responsibility of the PM and not anyone else.
Due to the complex nature of software lifecycle development, most of the mistakes occur during earlier stages of development a.k.a upstream activities viz., Requirement Analysis, Design Approach, Design, Coding, Unit Testing and Integration Testing. Of these most of the defects escape and creep during Integration testing. More focus and adherence to process can help control defects at the respective stages. For eg: identifying a Coding defect during initial unit testing is easier than finding the same from IT or from field. Even worse, if a design defect is identified during IT, it calls for repetition of the entire development cycle and hence it is worth spending efforts in effective design review and hence subsequent reviews.
How does a PM ensure that the reviews are turning into effective ones? The answer lies in conducting formal table reviews involving relevant stakeholders and capturing the data coming out of each reviewer. For eg: you could capture defects found per page from each reviewer and leading to overall defects per page. To accept and clear a design artifact, it needs to be within an acceptable lower and upper limit. Let us say it is at least 1 defect/page to a maximum of 3 defects/page. If there are more defects, it means that the author has not done his work properly. If there are no defects, that means reviewer has not done his part correctly. Ideally there will be defects in every page within the acceptable limits. That is what should be the focus. If there are no defects, well it is the ideal situation. However, there is nothing called a bug-free software.
Considering the above, it is always important to conduct reviews, capture the review metrics, ensure alternate approaches are considered at every stage of development and do a quantitative project execution and control.