Product Defects and Risk of Failure documentation best practices?
John WrightDevelopment Project Manager| Oregon Housing and Community Services - Disaster Recovery and ResilienceSalem, Or, United States
Hey everyone,
I am fairly new to project management and in my current project I am having to address defects in the product we have purchased and am wondering if there is a best practice in how you document the defects and their potential risk of failure? Also how you would notify the vendor with the list of potential defects? Saving Changes...
A lot of this goes back to the contract and the nature of the product itself. If there is a warranty period in place, you would follow the procedures outlined for that in the contract.
If there is no contract currently in place, then you'd likely need to define and document a defect management process for the product and determine how best to engage with the vendor's support team to resolve the defects. Part of this will be assessing the expected impacts to the project outcomes from the defects - that would be a major input into determining the severity of each reported defect.
Kiron
...
1 reply by John Wright
May 05, 2022 6:00 PM
John Wright
...
Thank you Kiron. That helps. I have also taken the Risk Management tool that Anna Tulchinski published and have modified it a bit to work as a tracker as well.
Saving Changes...
John WrightDevelopment Project Manager| Oregon Housing and Community Services - Disaster Recovery and ResilienceSalem, Or, United States
May 05, 2022 12:05 PM
Replying to Kiron Bondale
...
John -
A lot of this goes back to the contract and the nature of the product itself. If there is a warranty period in place, you would follow the procedures outlined for that in the contract.
If there is no contract currently in place, then you'd likely need to define and document a defect management process for the product and determine how best to engage with the vendor's support team to resolve the defects. Part of this will be assessing the expected impacts to the project outcomes from the defects - that would be a major input into determining the severity of each reported defect.
Kiron
Thank you Kiron. That helps. I have also taken the Risk Management tool that Anna Tulchinski published and have modified it a bit to work as a tracker as well. Saving Changes...
Relaying the problems back to the supplier whether this was a customized product with vendor support, or you bought a COTS product. Documenting the defects, characterizing them, and resolving the issues is one part technical, and one part PM.
My current day job is half technical, half PM but all focused on resolving vendor product issues. On the technical side, we keep a log of all problem reports. That includes data like severity (spectrum of nuisance to safety) which helps with priority to fix. Some questions you need to address are what functions and requirements are related to this problem. If you cannot perform them, what is the impact to your operations? Does the product interface with other products? The solution might impact other products you use where changing one requires changing another. Most of that comes from engineering, not PM.
Integrating the problem fixes is more in the PM realm. When do we need these fixed to support our business? When can the vendor fix them? What else might have to change when the fix is ready so we have an integrated solution.
One thing you mentioned is a bit unclear about what you said about potential risk of failure. In a safety intensive industry, that might involve serious calculations to determine probabilistic frequency of failure relative to critical functions. That's quite different than if the print button doesn't work, we have to take a screen shot. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
What you asking belongs to quality field. Because of that, it will depend on the type of industry where you are working on and mainly if the organization is certified in some quality standard or not. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
As Sergio pointed out, the management of defects rightly belongs to quality management. What comes out of those defects does belong to project management: risk management, time management, and integration management.
You want to focus on the project management side, leave the quality management to the QA team. As alluded by John, a risk management approach (identification, prioritization, mitigation, contingency, fallback) would be a great fit. Saving Changes...
Riad AlhammoudProject management| LanganAbu Dhabi, United Arab Emirates
Quality and contract management.
Quality control purpose is to check the final product. Corrective actions are taken in accordance with the contract. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Its a bit late to start thinking about quality failure once the product has been delivered. Quality management starts on day one when the performance requirements are established followed by QC and QA throughout the design and construction (service delivery). QM should be defined in the contract documents, performance reviews, progress reports, etc.
Too late to start worrying about best practice once the horse has left the barn. Your only option now is to try and find/catch the horse recognizing that this will take significant effort.
Potential responses from supplier:
1) you didn't tell us this is what you expected
2) you knew what we were doing throughout, why didn't you advise then
3) you were part of the decision making process and are equally to blame
4) we ere just following direction. Saving Changes...
