My  boss told me my job was to drive down the roughly 500 defects on our current project so we can ship it.  I did my research and found the current 500 defects in the defect database.  I also noticed another 500 issues in the database that were tagged as “work to be done” (WTBD).  I asked my boss about these and he said to ignore them. I watched both these lists for a few days and noticed that both were equally active.  New defects and work to be done were coming in daily and others were getting fixed daily.

As the project manager, I was concerned about these WTBDs, so I contacted each of the development managers and asked about them.  I finally found a manager who owned most of these.  His comment?  Yes, they all had to be completed.  This work to be done was actually more like “we noticed that there was a change or more work to be done” and these were used to document the work. Think of it this way, if a tester noticed the issue it was entered as a defect.  If the programmer noticed the issue, they entered it as “work still to be done.”

My boss said I needed to have daily meetings if we were to drive down the defects.  I now knew that we also needed to finish all the WTBD also.  I “drove” the defects on a daily basis, per my bosses preferred methodology.  At the  same time, I simply tracked the WTBD progress to see how they were doing.  What happened?  Both lists came down at about the same rate and once they both were small lists, the product was accepted by the customer.

The corporate common wisdom on how to achieve quality was a daily detailed meeting to focus on the defects.  What I discovered was that the “review” did not make any difference as to the speed of how fast we fixed the defects.  While I could see this by reviewing the trends before and after the defect drive down process started, it was also further substantiated by the fact that the other undriven list came down just as fast without a daily project status meeting to keep them going.

Too often we manage based upon habit or organizational past practices.  While many of these are good practices, we periodically need to review what we are doing and challenge our own assumptions.  We may be surprised by how these habits don’t really add value as project management tools and can be eliminated, saving time and effort.

Do you have examples of habits or practices that upon closer examination don’t provide the expected value?