The first condition required in order to be able to do quality work is to know exactly what is expected from you. Most of the time, this statement is associated with gathering accurate requirements and having the customer explain exactly what she is expecting. However, there are always another set of implicit requirements, apart from the customer's functional requirements. These requirements are derived from the quality standard of your organization. Let's take for example the quality of source code. An organization that does not let its developers know what is expected to them in order to produce quality source code, cannot expect them to write such code. This is like trying to conform to functional requirements without specifying them first. Yet, this is exactly what happens in many organizations. It is very common to have a coding standard document, which developers should comply with. Yet, such an organizational standard often describes nothing but technical aspects of writing source code, such as what notation to use, how a class name should be prefixed and what should the structure of the code comments be. With all due respect, source code could easily comply with such standards and still be of poor quality. In order to achieve real quality, the organization should deal with the essence of the problem: the design of a component, the structure of the code, the code complexity, and common coding errors. Naturally, this is hard to achieve in a written standard. So, the best approach to this problem is investing in education. There are many things an organization could do in order to get everyone to know the quality standard expected from them. The first thing is to establish a constant formal review that is oriented towards improvement instead of criticism. By letting developers know what their mistakes are and how they can avoid them the next time the organization can slowly direct them in the right direction. In addition, the organization can arrange for seminars in which case studies will be analyzed in order to identify quality soft-spots in source code and how it could be improved. Such simple measures will spread the word around: not only quality is important, now everyone knows exactly how to achieve it. Of course, the same idea could be easily applied to every other aspect of the development process: design, testing, developer tests, etc. Merely saying we need to improve quality is not enough. People should realize exactly how this could be achieved, by first knowing exactly what is expected from them. If quality is part of the requirements, it should be treated in the same manner.