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.

Quality in Innovation

This post is my personal opinion and does not reflect the opinion of my employer... yadda, yadda...

I'm reading several books at the moment, one of which is the book to CMMi. This is basically deriving a vision for continuous process improvement in a company. But there are things seriously wrong with CMM. It is geared towards establishing a "static" state atmosphere, because if this were different, it would be very difficult to apply measurements across the process. A dynamic setting like an innovative powerhouse has severe problems adopting more rigid procedures due to the nature of their work. It is *not* a factory and they work with people that are intelligent and know what they are doing. Why insult them with procedures that tell them what to do, if they are the ones that know best?

The final level of the CMMi Zen approach is: "the optimizing level" :). I compare this to an engine room of a ship (I used to work in shipping).

This is where every process is defined and measured, you have all the spare parts you need, you have all the supplies you need and the ship hums along without a glitch. No leaking oil, no weird sounds, there are no bearings about to break or go. The chief engineer only walks around to tweak some settings on regulators for the form of it, puts his ear against a machine to hear its performance. It might tell the 2nd to replace a filter here or there or schedule an overhaul in the future, but overall the performance is so magnificent that everybody can go upstairs to the ship's bar. That's Zen, but software is pretty much different, especially when working on innovative and new products. Technology moves a *lot* faster in IT than it does in shipping. The speed at which new technology can be consumed on the ship is because they are users of that technology, not creators. And in software you may find yourself working on an embedded system to monitor cars first, subsequently followed by the latest technology in Ajax to create a project management system.

The later parts of my 729-page CMMi guide talks about "statistics" and "statistically managed subprocesses". Surely it must be evident that if you are not continuously repeating what you are doing, you are not building any historical data and thereby not creating the data necessary to improve your processes.

The real reason why it is so difficult to integrate with these quality visions is because in IT we are learning new things every day or encountering problems that are not standard. If I was working on a project with really new technology or bending the rules of what is possible with that technology, I would deserve a couple of days extra to find out ways and alternatives. I might choose a wrong alternative first and then have to rework. I might have to read through books of protocols in order to even start with architecture or coding. I may have people in the team that need to be trained.

Is a quality process that relies on repeatedness able to improve the quality of what I am doing?

....

I am not convinced!

( also check out http://www.joelonsoftware.com/articles/Craftsmanship.html )