You’ve probably heard it all about software quality. From the ISO criteria to test driven development, code metrics and reviews to automated system tests. It all sounds nice and appealing, and it is all very suitable to incremental product development with scrum and well defined processes for an established product and with sufficient budget. When you are managing single individual projects though, there is always one ingredient that is missing in those explanations about how to reach good quality: It’s the project plan.
And the more your environment lacks standardization of processes, the more important the project plan gets. So what do I mean by that? I will explain.
If you don’t plan it, it will not happen
Software quality happens not by default. Although there is a famous saying that you cannot test quality into software, I have rarely found the situation that software quality is anywhere near the expected levels without sufficient quality assurance measures. And those need time and budget. But of course software quality starts much earlier. Having good requirements is the most important part. If you are implementing GUI applications you will need to invest in usability engineering, creating mock-ups and usability tests.
So the most important thing a software project manager has to do in regards to software quality is to schedule tasks and allocate budget for activities that produce and secure software quality. And those activities happen before, during and after the coding. A project team cannot start coding if the requirements engineering has not been done well. Not even in an agile project. During the development, there might be code or design reviews. Activities that have to be included in the project plan. After the software has been developed, the project plan has to include time for testing the software.
So your quality sucks. What now?
Testing is only the half the battle. After you have found out that the software has bugs (which it most likely will have), someone will have to fix them. So the software project plan also has to include time and budget for fixing bugs after the testing phase. But this is still not enough. After the software has been changed it will have to be re-tested, because some of the fixes might have introduced new bugs. So the project plan will also need to include time and budget for the re-testing. And so on… The same applies for all other quality assurance measures that might trigger rework such as code reviews.
But then we could test forever
Of course a decision has to be made when the ROI of all the quality assurance measures turns negative. The goal is not to deliver software without bugs. The right amount of quality assurance is reached when the marginal damage from an additional bug equals the marginal cost of the required additional quality assurance measures to find that bug in advance. That sweet spot is hard to find and can probably only be estimated. But it is important that you always remind yourself that quality is no end in itself. It is only a means to an end: profit, customer value or some other measure of success.
The Nerd Manager 