Quality is job #15 (This week in pm-clinic)
This week in the pm-clinic discussion forum– Quality is job #15:
Here’s this week’s situation:
We just shipped v2 of our project – but few are cheering. To meet our dates we dropped quality on the floor (reliability, usability… you name it) and everyone knows it. There’s already talk about what commitments we have for v3, but no one has articulated what we’re going to do about raising the quality bar.
How do you (successfully) argue for time for higher quality? Has anyone worked on a project where quality was really job #1? How did it happen? Who defined (and defended) quality?
– Quality is job #1
Sounds more like Vista :D
Or maybe not.
But what is the point in making a release if there is no reason behind it ?
I mean, can you “measure” progress from v1 to v2 ?
That by itself should answer all questions. Releases should ensure that there is progress in some functional or non-functional requirement fulfillment.
Fixing bugs is progress.
Increasing performance is progress.
Scaling product usage is progress.
I dont have to say more. The moment you’ve attained significant progress to ensure a happier customer, you can make a release. Be it a day or even a month.
And as most of the smart managers do, treat deadlines drawn from estimates as ESTIMATED DEADLINES. Trace back from the deadline and see if the objectives for that deadline are achievable. If not, prioritize the additions or changes. I guess this is what any textbook would say as well.