Checklists and Signatures
The essence of consistency in a team environment is to ensure that everyone knows what the important tasks are and to make sure they get done.
In software development, many situations lend themselves wonderfully to the use of checklists. Whether it is a list of items that need to be considered when initiating a project, design paradigms to be aware of, elements to watch out for when coding (or reviewing code), test cases to consider, or steps required to build or release the software, a checklist keeps the key information all in one place.
When used as a supplement to a more comprehensive form of communication such as policies and procedures, checklists carry the essence that can be tacked on the wall and referred to repeatedly. They can also be maintained tactically to remain relevant.
Unfortunately, all these efforts of capturing and disseminating what is to be done count for nothing if there is a risk that the tasks are going to be neglected anyway.
With software, however, we rarely see this.
Document signoff has often become an administrative activity. Many organizations (even those with fairly weighty defined processes) have very little accountability associated with activities such as checking in code or even releasing software. Although configuration management (CM) systems can be used to forensically identify the check-in culprit, few organizations have mechanisms in place to enforce a "standard" list of pre-check-in activities such as peer review and unit and regression testing.
This is interesting, because the ramifications of failing to follow the right steps in software development can often be more similar to the results of an in-flight failure than to leaving the toilet paper roll empty. The cost of putting simple accountability in place is much less than the cost of relaxed or uneven enforcement. An ounce of prevention....
It is all about stating what you are going to do and showing that you have done it.