by Shaun H. Ajani

It all starts in the beginning. As a Project Manager, planning is the most crucial part of the project. However, planning does not end, when the product is fully coded, even if the QA is scheduled for a completely different department. When the application finally goes into production, the Project Manager must be held answerable, if something major goes awry. And there is good reason for it. According to the Gartner Institute, if an application goes down in an unplanned fashion, the company loses $100,000 an hour.

The Extreme Project Management principle dictates that Project Managers conduct their own QA, before it is passed on to production. This is not the same QA as performed by the QA department; the Project Manager's process resides at a higher level in the big picture, specifically to track the defects, at a minimum, before it leaves the Project Manager's capable hands.

The Process

Any good Defect Tracking program starts by planning the process. For this purpose, it is best to stay at a high level. A typical process that I have used in the past is the TDT (Trifold Defect Tracking) process. The reason it is called Trifold Defect Tracking is because if you put the process flow down on paper, and fold the paper in three places, the process is broken down in three clean sections.

Section one is the 'Origin'. In this section, the tester discovers the defect and logs it in a pre-existing (discussed later) form, then forwards the defect form to the individual team lead for that particular build. It is important to remember that there must be one, and only one contact, for each build or module. It is the responsibilities of the team leads to further disseminate the information.

Section two is the 'Leader Decision'. In this section, the team lead, decides what priority to give this particular defect. This is done in conjunction with the business side. This section is also known as the 'Political' section. It may be painfully obvious to the IT team lead what the priority of the defect fix should be; nevertheless, the business side has to be consulted. Low priority items, such as cosmetic issues, can be sent to a pending area, while high priority items, such as code defects can be routed through the process.

This leads us into the third section, which is the 'Assign and Fix' section. This section is the simplest of all, but the most time consuming. The team lead assigns the defect to a developer to be fixed. Although, this is a 'defect tracking' process, the fix must be completed, before TDT process can be declared finished, as the goal is to have the application ready to go to the QA department, not just to 'know' what the defects are. There will be many QA processes that the Project Manager may not have the resources for, like Load Testing, which are traditionally done in the QA department. But an Extreme Project Manager makes it a priority for the application to be in 'as perfect as can be' shape, before it is presented to QA.

Documents

The good news is that the TDT process only takes two pieces of document to complete. As always, I will insist that a professional Technical Writer is used to create forms and other documents. The two pieces are the TDT form and the TDT database.

The TDT form is a simple form created in Word. It is made available to every tester on the team. The tester merely fills out the form, which consists of fields, such as Defect Number, Defect Description, Module or Build, Date Opened, Priority, Date Closed, and Tester Name. The database is an uncomplicated Access database, which mirrors the Word form exactly. For example, each of the fields in the Word form corresponds to the field on the Access table.

Lab

Before the TDT process begins, ensure that the testing environment does not have a huge disconnect with the true production environment. It is not expected for the IT Project Manager to have access to all the bells and whistles of a QA department's lab, but some reasonable reality reproduction is expected.

For example, a few years ago, I was at a major Fortune 500 company, working on a state-of-the-art product, used in emergency vehicles. The core usability existed while the vehicle was in motion, possibily at high speeds. However, the lab environment consisted of a few prototypes connected with all kinds of different off the shelf cables. This is the kind of disconnect I am referring to.

Finally, it is certainly the responsibility of the Extreme Project Manager to ensure that all the components come together at some level. The TDT process works best, when it is in sync with the rest of the QA mechanisms, whether it is at the development, under complete control of the Project Manager, or at the production level.

Special thanks to Shaun H. Ajani for allowing Borderwave Software to present his views. The ideas presented here are Shaun's own theories, and are only used with proper permission. Please visit http://www.ajani.com to learn more about AJANI RESEARCH INC.