tag:blogger.com,1999:blog-3322141.post8801315694750073309..comments2023-10-24T23:22:27.416+10:00Comments on More News: Within SpecificationUnknownnoreply@blogger.comBlogger1125tag:blogger.com,1999:blog-3322141.post-23156685280605080682007-02-06T14:14:00.000+10:002007-02-06T14:14:00.000+10:00Well I guess the quality of the specification is d...Well I guess the quality of the specification is different to the quality of the product. <br /><br />I run a defect management process that basically says 'anybody who doesn't like something raise a defect'. Some of this is planned testing and some isn't - but it's all considered a quality measure.<br /><br />It's only after the defect is raised that we decided if it is a specification defect, or a code defect, or a project initiation defect, or the PM's fault, etc... <br /><br />It's the project's defect (not the developer's) until we decide what/who more specifically is at fault.<br /><br />If the code is just following the specification then the specification is at fault. If the specification is part of the terms of the contract we change the contract and maybe even classify the defect as a 'contract defect'.<br /><br />If the contract is wrong because our vendor screwed us then I guess it's a 'supplier relationship defect', or even an 'IT strategy defect' so we might have to change vendors, or strategy, or you maybe should just buy a new car.<br /><br />What I find really interesting that within IT organisations only the technical work products are subejcted to a defect management process. I've often tried to raise a defect an IT Strategy - but I don't get very far.....Matthewhttps://www.blogger.com/profile/12199459552191461436noreply@blogger.com