Quality Management of Software Projects, Part 2: Preemptive Strike

In my previous article, I introduced a definition for software quality, and described the challenges caused by a conflict of interest between different stakeholders. As promised, this article will describe preemptive measures, which reduces or eliminates quality problems of a software project, when taken before the project is actually "started". Cooperation between the members of appearance and implementation groups is required to maximize the acquired benefits. The preemptive measures have been divided into following groups:

Recognize your needs. Obviously, this is the most important precondition for any project. If you don't identify your requirements, you might end up spending a lot of money without getting anything useful as a return. So, do yourself a favor, and spend some time to identify and document the requirements of the software. If you are planning to arrange a competitive bidding for subcontractors, pay extra attention to this phase, and write a requirement specification before the competitive bidding is arranged. This is the only way you are going to get realistic offers. On the other hand, if you are willing to accept a project using hourly based pricing, you don't necessarily have to finish the whole requirement specification beforehand, as long as you can feed the requirements to the developers before they run out of work. In any case, you should have a clear vision of your needs before starting the project.

Select the correct subcontractor. Selecting the used subcontractor for a project can sometimes be a demanding task, since comparing the different subcontractors is not an exact science. When considering that the subcontractor selection can have a huge impact to the outcome of the project, pressure to make the right selection can be high as well. Luckily, It is possible to formulate a few general guidelines for subcontractor selection:

  • Subcontractor evaluation. When evaluating an unknown subcontractor, start with a small pilot project, if possible. This way you can easily find out, if the subcontractor can be considered as a candidate for bigger and more demanding projects. Also, always ask references with contact details. Contacting the previous customers of a subcontractor can provide you invaluable information about their true ability to fulfill their promises. You might also obtain additional information by utilizing your contact network and finding out, if your contacts have got experience working with the evaluated company. And one little thing, do not forget to investigate the financial state of the subcontractor. You might want to think twice before doing business with a company, which has got financial problems.
  • Competence evaluation. This is actually a part of the subcontractor evaluation process, but I wanted to emphasize a point, which is sometimes forgotten. It makes absolutely no sense to ask: Do you have got previous experience from technology X. The answer to that question is almost always yes. Instead, you should find out which technologies were used in their reference projects.
  • Competitive bidding. If you are asking offers for a fixed price project, always remember to check that the work estimates, schedule and pricing are realistic. If they are not realistic, move on to the next subcontractor. Trying to get a deal, which is too good to be true, is a sure way for failure. Also, remember that it is a really bad idea to use price as an only selection criteria. First, usually cheap price increases your total expenses, because you have to spent more time on project management and quality assurance. Second, you get what you paid for. You cannot expect to get a Ferrari for a price of a Kia.

Make a commitment for quality. No one builds a house without proper supervision, which ensures that building regulations are being followed. Thus, it is very hard for me to understand, why quality management is not taken seriously in software projects. It simply does not make sense that companies do not want to protect their investments. However, if you want to ensure that you are really getting what you paid for, you have to decide the used quality assurance actions and commit to your decision. Trust your technical personnel, and let them determine, what kind of actions are needed to ensure the quality of the architecture and the source code. To prove your commitment, you must also assign resources for quality assurance during the project.

In a situation, where you do not have got enough competence to write down your requirements, evaluate different subcontractors or plan and execute the quality assurance actions, you should definitively hire external consults to help you out. This might cost you more than a few bucks, but I promise you that it will be money well spent. This option gives you more freedom to concentrate solely on describing the business problems, which you want to be solved by the created software, and helps you to protect your investment.

We have now discussed preemptive methods used to reduce or eliminate quality problems during a software project, and agreed that customers should recognize their needs, select the correct subcontractor and make a commitment to quality assurance. However, there is still one important lesson to be learned: Always honor the “holy triangle” and its golden rule: Good, Cheap and Fast. Pick any two. By the way, I was a bit vague while talking about the quality assurance methods of a software project. I will get back to that topic in my next article.

0 comments… add one

Leave a Reply