Home construction requires conformance to a number of building standards (for example, NHBC in the UK), and standard practices and apprenticeships/training help to reinforce consistency between construction projects. In the IT world, the best approach to building a quality system that ensures all involved in a project are fully aware of what part they play is to use software engineering "best practice" principles.
For a more thorough understanding of software engineering best practices, I highly recommend Steve McConnell's book Code Complete: A Practical Handbook of Software Construction (Microsoft Press, 1993), but this list represents an overview of these practices:
Effective technical and business planning processes
Effective technical and business design processes (including technical architecture design)
Source code control/version control
Regular QA checks of all the above
During the development phase of a project, coding standards are absolutely essential. Good coding standards enable developers and designers to know the "rules" of the project (which components belong to which parts of the architecture, where to find files, look and feel information, and so on); to ensure consistency; reduce rework and redundancy; reduce the number and effects of problems caused by mistakes; and aid code maintenance to a great extent.
For example, good naming standards can make it intuitive and easy to do the following:
Find files/packages in a large directory system
Work out what a variable does
Work out what type a variable is
Work out what a method/function does
Unlike in the house-building scenario, in IT the maintenance aspect is particularly important. As pointed out in McConnell's book, 80% of development work is in the maintenance phase of an IT system, and code is often used long after the original developer expected it to be usedas the Y2K issue a few years back made only too clear. Because it's so likely that most of the work on a piece of code will not be carried out by the original author of the code, it's essential to make it is as easy as possible for other developers to understand the code. Meaningful variable/file/directory/object names, good naming conventions, logical and documented file/directory structures, good layout, and good commenting can all help.
McConnell provides some good tips in these areas; in fact, he regards the naming of variables and objects as so important that he devotes whole chapters to this topic. He also provides little nuggets of wisdom that can provide ammunition in the fight to get good coding standards enforced within an organization; for example, he points out that research shows that indenting lines of code by 35 spaces boosts comprehension by 68%, whereas indenting by 6 spaces decreases comprehension by 32%! He also provides some very good cost justifications for putting in the extra time and effort to develop and enforce coding standards, with some great figures and graphs showing how much time can be saved.