品質尺度は、品質を測定するためのモノサシのことです。

品質マネジメント計画でアウトプット（決定）し、
品質コントロール、品質保証がインプット（使用）するものです。
もちろん、マネジメント・チームではなく、実装部隊が使います。

品質尺度が、品質マネジメント計画書のコンテンツという解釈でもいいと思います。
てか、その方が自然だし。

PMBOK®ガイドが、品質尺度をアウトプットとしてわざわざ別立てで挙げているのは、何かしら言いたいことがあるから。

かな？

と思ったら、大したことは書いてないんです。これが。

（苦笑）
えーと、まずですね。
品質マネジメントといっても、とにかく、測ることから始まるということです。

ツールと技法にある、品質7つ道具たって、その測った結果を分かりやすく表示するためのものですから。
なにするにしたって測らないことには始まりません。

そして、測った後に、統計処理を施し、対策へとつなげていくわけです。
測らないことには改善策なんて打てないし、
策の良し悪しも評価できません。

当たり前すぎるでしょ？
でも、現実はそうでもなくてね。

例えば、
顧客満足をどうやって上げていけばいいのか？

なんていう会議をやっているにも関わらずですよ、

リピート率は？
利用者数の推移は？
クレームで最も多いのは？

というようなことに、誰も答えられない。
なんてことがあったりするわけです。

PMIが策定する、プロジェクトマネジメント成熟度モデル（OPM3）でも、
成熟度のステップとして、

標準化⇒測定⇒統制⇒継続的改善
とあるように、まずは測ること。

そして、
押さえておくべきは、品質尺度とは、極めて具体的な言葉で表現できなければいけないということです。
数値化と言い換えてもいいかもしれません。

きれいであること、
滑らかであること、
詳しいこと、
使用に耐えうること、

こうした表現はいずれも品質尺度として機能しません。
測れないものをコントロールすることはできないんです。

具体的に何にするかは、これは専門領域の論点かもしれません。

工業製品などであれば、長さや、重さ、速度など、比較的簡単ですが、サービス、顧客満足などのいわゆる定性的なものは、どうやったら数値化できるかを考えないといけませんね。

しかし、測定し、数値化する、という指針に例外はありません。
継続的改善のためには、何かしら、追いかけられる品質尺度を見つけないといけないわけです。

一応、PMBOK®ガイドの例示を見ておきましょう。
これもサラッと。

• 期日達成率
• 欠陥頻度
• 不良率
• 可用性
• 信頼性
• 試験網羅率

PMBOK®ガイドには、これらの用語解説もありませんので、よくわからないものもあるんですが、

期日達成率：
これは色々考えられますね。
予定日数÷実績日数
とか、あるいは、
予定内達成アクティビティの数÷全アクティビティ数
とか。
いずれも大きい方がハッピー。

欠陥頻度：
欠陥製品数÷生産数
とか、あるいは
欠陥発生数÷稼働時間
とか。
これは、いずれも小さい方がハッピー。

不良率：
これは有名。
不良数÷総数（良品数+不良数）
これも、小さい方がハッピー。

可用性：
これも有名。
稼働率ともいいます。
実際に稼動した時間÷稼動すべき時間（稼動した時間＋止まっていた時間）
これは、大きい方がハッピー。

信頼性：
これも有名だけど、表現にはいくつもあって、
上記の可用性もその一つ。
これも、大きい方がハッピー。

試験網羅率：
これも比較的有名だけど、表現は色々。
要は、
試験した数÷試験すべき数
これも、大きい方がハッピーです。

ソフトウェアだと、
実際に走らせたステップ数（コードの行数）÷プログラム全ステップ数（コードの全行数）
とかが使われます。