What I miss from the above are other properties that people should have, beyond formalization and communication and skills. It should be easy to defend that project success depends for a very high percentage on communication and its quality.
But communication is an expression of our ideas, and then my argument would be that the correct ideas should exist before we are able to communicate efficiently with others to align the team and project with those ideas that would guarantee the success of a project. So... what is more important? The efficient communication itself between the team? Or the formation of the (correct) ideas itself in the first place?
My thoughts are basically revolving around the idea that... if I were to re-design or re-think software quality as a concept, how would I explore the limitations, shape this area of thought and come to new conclusions and realizations of what, from a cognitive perspective, really goes on in an individual's mind during the development process and how this can be very strongly influenced by the communication within the team. I reckon that from this perspective on quality, personality is more important than technical skill.
Some initial thoughts that could start this theory are:
- Personal traits and attitude that seek out error are far more important than any compliance with rules or regulations.
- Quality cannot be undoubtedly and efficiently measured without establishing clear criteria with the user or client.
- Thought pattern development, problem analysis, conflict resolution, behaviour etc. are not generally part of quality theories (unless you accept the very vague terms in ISO/CMM documents that might just mean about anything).
- The nature and objective of the project should be very clear from the start.
- Software engineers should understand general errors of thought and learn to voice concerns more readily and harshly.
- Disposition towards stakeholders may put pressure on engineers to change their response.
So, my focus and view on quality in this post is to ramify about identifying cognitive processes and nature of the human mind that are most contributing to developing quality software. So, rather than thinking of process as a set of rules and actions, I regard process as a set of traits, attitudes and motivations that someone needs to develop in order to develop high quality software.
Traits, attitudes and motivations can also be called company culture. If we understand how we can influence this culture from within, we should have the capability to improve the quality that a certain person is able (and willing) to develop.
But there is another problem here. Without a framework for measuring the level of quality produced, the entity has no means of knowing whether their actions are effective. This probably requires frequent peer reviews and other means for measuring compliance in an attempt to adjust traits, attitudes and motivations, all to become more efficient all the time and eventually contribute more significantly to this process of self-enlightenment.
The problem here is the same as the one indicated at the start. There are (not yet) true absolute criteria of measuring software quality. Any attempt to establish such a criteria has so far resulted in a total mess, since the entities that are impacted by these criteria attempt to maximize on the goals given to them individually. This is because these criteria are often aligned with promotion factors or budget allocations.
There have been good successes, because the factors that indicate quality can differ from one project to another. Now... given this is a truth. How can we ever consider to develop a framework or "standard" of quality that encompasses each and every different situation or project? Standard in the sense of rules, regulations and processes as actions.