Lessons in project quality

Tanmay Vora
Posted on

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!

1 Comment

Tanmay – Great info on quality and software development. Testing is so critical to releasing quality code or software yet often that is the phase that gets crunched on technical projects. It’s good to see you and others, like CIO, taking on the issue.