Is a formal IT development process like ISO and CMM a cognitive substitute?

Not hindered by any lack of knowledge once again, I'm asking myself some questions on what the real factors for IT project success are. These factors are often broken down as planning, skills, communication and formalization of a development process (like ISO, CMM, etc.).

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.
  

A natural reaction when encountering a problem, accident or incompliance is to establish rules and guidelines that people need to adhere to in an attempt to prevent similar occurrences. This might also stimulate a certain no-thought attitude where rules and guidelines are simply followed without understanding the actual matter and nature of the job. It can also falsely be used as a means to indicate progress. The latter can result in very serious problems developing until it's too late to recognize them. It might also result in a couple of people that know and a couple of people that follow blind.

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.