Browse Prior Art Database

Method of Defect Prevention in Project Oriented Services Disclosure Number: IPCOM000197725D
Publication Date: 2010-Jul-20
Document File: 5 page(s) / 54K

Publishing Venue

The Prior Art Database


This invention describes the end-to-end process developed to capture, classify and analyze defects encountered throughout the various phases of a Project Delivery Lifecycle. This methodology for a Defect Prevention Process (DPP) meets the unique requirements of Project Delivery within a Services Organization framework. The process described relies on organizations to consistently collect data and perform a Root Cause Analysis (RCA) in order to identify a solution to the problem and prevent future occurrences.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 39% of the total text.

Page 1 of 5

Method of Defect Prevention in Project Oriented Services

Many of the mainstream Project Management methodologies have definitions for improvement process. However, there is no end-to-end process defined specifically for a Defect Prevention Process (DPP) within Project Delivery practices. For this context, the definition of defect is: any result that is not the expected outcome.

Most of the published DPPs center around Problem and Incident reporting that typically relies on core process tools such as those provided as sub-modules of helpdesk repositories. These tools do not adapt well into Project Delivery scenarios for the following reasons:

Volume of tickets raised:

A problem/incident ticketing system potentially manages thousands of tickets per day (sometimes as a result of automated monitoring agents), very quickly gathering significant amounts and generating meaningful statistics. These statistics provide information for a Root Cause Analysis. In Project Delivery, however, the volumes of defects generated are perhaps only numbered in the dozens of items per day, providing less opportunity for Root Cause Analysis.

Format of tickets raised:

Typically, helpdesk systems operate in break/fix-type scenarios of a very common and often repeated nature, such as common hardware or software failures (e.g., a hard-disk failure or password reset issues). Systems and personnel classify and analyze such tickets in a very structured manner. In Project Delivery, quite often the defects arising are of a more generic and variable nature (e.g., human resource availability issues, solution design issues, hardware not being delivered on time, etc.). Many of these defects are more difficult to neatly categorize; therefore, they are logged as category "other" or "unknown" which makes it difficult to perform a meaningful statistical analysis of the collected data.

Project Delivery organizations have traditionally worked on the premise that if a process encounters issues midstream during a delivery cycle, then it is the Project Manager's (PM)

job to quickly fix the immediate issue. The goal is to keep Project Delivery on time

and meet the delivery schedule. Within this traditional process and with the traditional mindset of fixing the immediate problem in order to move ahead, the PM's might not, for whatever reason, document every defect as it occurs. Herein lies the challenge: unless all defects are logged and analyzed, there is potential for the defect to keep occurring both within the current project and all subsequent deliveries.

The solution is a methodology for capturing and classifying defects as they are uncovered within various stages of Project Delivery. This Defect Prevention Process (DPP) improves the efficiency of Project Delivery by removing the root cause[s] of a


Page 2 of 5

defect and preventing such defects from reoccurring. The system identifies the trigger mechanisms for instigating a Root Cause Analysis (RCA) process, and subseque...