Quality Manament of Software Projects, Part 1: The Conflict

As reported by Computer Business Review Online, the results of the latest Standish Group report are devastating. According to the Standish Group, the number of last year's software project failures were the highest in five years. This makes me wonder, whether there is something essentially wrong with the way project management and quality management is done in software projects. These thoughts are the motivation behind this article series, which concentrates solely to the quality management of software projects.

Before going into the details, we must have some kind of definition for software quality. One definition is given by Wikipedia, which states that:

Software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions. It is often described as the 'fitness for purpose' of a piece of software.

At first this definition seem sound. However, according my experience, different stakeholders of a software project do not share the same expectations for software quality. To make matters “worse”, not all stakeholders have the same amount of influence over the decisions made in the organization. The conflict of interests seems to be born.

The different stakeholders of a typical software project can be roughly divided into two groups when using their expectations for software quality as a dividing factor:

• Appearance. Stakeholders belonging to this group measures the quality of software by inspecting its functions and user interface. Asking questions like: “does the software work as expected” and “does the user interface look appealing to users” are used to analyze the quality of software.
• Implementation. As the name suggests, stakeholders, who are concerned about the quality of implementation and software architecture, are members of this group. Readability, maintainability and testability of source code are the main concerns of these stakeholders.

At first, one might feel compelled to ask, what is the problem? After all, both groups have valid requirements for software quality, and all aspects of software development are pretty much covered. In a perfect world, there would be no contradiction between the goals of these two groups. However, to the most of us, the world we live in is far from perfect.

As I mentioned earlier, all stakeholders do not have the same amount of influence over the decisions made in an organization. Also, the stakeholders having the most influence, are usually members of the appearance group. Thus, the schedule and scope planning of a software project as well as resource assignment are on the hands of the appearance group. Possible bad experiences of previous projects can also increase tension between groups, since they tend to strengthen the stereotypic images about the representatives of different stakeholders. This raises a challenge for the entire organization.

Organizations are symbiotic creatures by nature. They simply cannot be successful, if one of the needed stakeholders is absent. Rather than creating barriers and borders, software projects should be seen as joint ventures, where the key to success lies in the balance between the introduced groups. It can be challenging to select the best part of both worlds, but domination of either one of the two groups will surely lead into problems, which can have a drastic effect to the organization and its business. The question is, how this balance can be achieved?

We have now defined the term software quality, and identified the challenges awaiting us. A goal for our imaginary organization has also been set. The needed actions are still unclear, but this article series will guide us through the phases of a software development project, and describe actions used to reach our goal. The next article talks about pre-emptive actions, which should be taken to reduce or eliminate quality problems of a software project, before the actual project is even started.