Good post. The only quibble I could have is that almost everyone understands what "Quality" is yet it requires education and experience to understand "Scope". Maybe that's a conversation/education you have with prospective clients though.
> The only quibble I could have is that almost everyone understands what "Quality" is yet it requires education and experience to understand "Scope"
I would say that's a feature, not a bug ;)
Everyone "knows" what quality is so nobody wants to cut it. The client expects a deliverable with a (mostly) bug free deliverable, and the developer expects to be able to try to create a codebase with as little technical debt as possible.
There are certainly situations where quality is cut (technical debt that you might avoid if you had more time, the customer deciding to skip beta testing), but as a developer I can't say, "You want this cheap and tomorrow, so we as a team are going to ship a buggy app". Because the first thing the client does when they give the app like that a spin? Come back to the developer with a bug list a mile long and say the current quality is unacceptable.
So then it's not the project management triangle of, "You take two sides, I'll take one". ;)
But if, as a developer, I say, "You want this cheap, and tomorrow, which means this thing needs to have two of these things you want, not all 10. Help me choose the most important things here." Which is a hard conversation (nobody wants to kill their darlings) but you can quantify scope (estimate and prioritize the work).
We certainly know a lot about quality from Deming, Juran, and Pirsig, but the margin is too small, and the night too short, to put this conversation in that scope.
