Lessons in project quality

We all know that Quality on a project is everybody’s business and right processes have to exist to ensure that everyone thinks about quality – be it review mechanism or having a set of metrics. Around the same time that I was thinking of documenting my learnings on this topic, I came across an article “Quality Doesn’t Just Happen“over at CIO.com which also documents lessons on project quality (included below are the ones which resonate well with my own learnings) :

“Lesson #1: Don’t reward for shipping on schedule. Anyone can ship garbage. Base rewards on quality metrics

Lesson #2: Don’t reward heroes for their Herculean effort late in the project to fix problems that could have—and should have—been fixed by the same people much earlier in the lifecycle.

Lesson #5: It’s easy to ignore documents that are sent by e-mail for approval. No response does not equal approval: No response means, “I didn’t have time to read it.”

Lesson #6: Don’t start coding until the requirements are stable and understood, or else budget time for subsequent rework.

Lesson #7: Code isn’t “complete” until it works. Good unit testing is part of the development effort, not an optional item to be jettisoned when the schedule is tight.

Lesson #10: Buggy software takes longer to ship. “

Any additions that you can suggest to the list above? Help me while I think of a few more!