Does Quality always get the respect it deserves as one of the key tradeoffs of project management? Here's an interesting article from InfoQ, a reflection on a talk of Ken Schwaber's, "Sacrificing Quality should be an Executive Management Decision", that I found through Carnival of the Agilists. I think Ken Schwaber's ultimate point is something like this:

Traditional project management focuses on tradeoffs involving time, scope, and cost. Quality is not as explicitly managed. Therefore, quality can be sacrificed at any time for any reason by any individual on the development team.

We now have reason to believe that high quality work actually gets things done faster. Less rework, etc. So quality should be re-emphasized, and the decision to cut corners should only be made strategically by the product owner and never by the development team.

The response is interesting. A lot of people said (kinda rudely) how stupid it was to assume all projects require high quality, and how stupid it was to push everything to the CEO. Well, they're half right. The point is, it's management's call. How high in management, well, that depends on the project. Basically, some people were distracted by the word "CEO", and I'm not sure if that was Ken Schwaber's or the poster's wording.

Anyway, the response illustrates exactly the response many people will have to the idea. I think to those of us that have studied these issues the choice is pretty obvious. So, I have two questions:

Product owners and managers need to ask for high quality work, instead of just getting the job done. Historically they always asked for the opposite. They will also need to fund a test for high quality work. I think actual code reviews may be required. (I don't think a set of passing unit tests is quite sufficient here, because the model itself is one thing that should be reviewed.)

How do we educate the product owners and managers to be able to make these decisions? I agree with Ken Schwaber that these are the people to who should make these decisions. Though I'm not sure they'll buy the "Quality Costs Less" principles easily. I've learned that "Technical Debt" was an astonishingly easy concept to introduce, perhaps because people were already familiar with the idea and finding a name for it made communication easier. Perhaps I can rephrase it in those terms.