ここでは、「計画」でやっていることを説明する。
――――――――――――――――――――――――――――――――
■「計画」でやっていること(品質)
品質は鬼門。PMI にとっての「品質」は、一般的なソレと違うので要注意。そして、かなり厳密に適用しようとする。
品質とは、本来備わっている特性がまとまって要求事項を満たす度合い。あるべきものが、ちゃんと備わっていること、とでも言い換えればいいだろか。「あるべき」は「暗黙のニーズ」「明示された仕様」のいずれかの形はとるかもしれないが、要求が満たされている=品質を満足しているといえる。
さらに、要求を満足するだけでなく、使用適合性(fitness for use)も必要だという。要は客の言うとおり作っても使えなきゃ意味ないよ、ということ。
それだけではない。品質マネジメントでは、成果物マネジメントだけでなく、プロジェクトのマネジメントまで目配りしなければならない。つまり、「良いものを作れば品質はOK」ではなく、そのプロジェクトのマネジメントそのものも「良く」することが重要だという。製品不良率が小さいだけでなく、手戻りが少ないことも大切。
その結果、「そのプロジェクト」だけで品質マネジメントを成し遂げるのは困難と言うよりも、ムリ。母体組織による継続的な改善活動が必要。また、後に出てくる「品質コスト」、特に予防と評価への投資は、母体組織で負担することになる。プロジェクトは有期的だからね。
実行や監視・コントロールプロセスに先行して説明するが、品質の3本柱はコレ↓
- 品質計画(計画):そのプロジェクトの品質規格を採用し、どう満たすかを決める
- 品質保証(実行):品質を満足するために、やるべきことをちゃんと実行する
- 品質管理(監視・コントロール):決めた品質規格に適合しているか判断し、不満足なパフォーマンス要因を取り除く方法を見つける
8.1 品質計画
どの品質規格がそのプロジェクトに関連するかを特定し、どうやってその規格を満足させるかを決める。品質は、計画・設計・作りこみによって達成されるものであり、検査によってではないことがポイント。品質コスト(適合/不適合コスト)、品質マネジメント(デミング、ジュラン、クロスビー)、品質ベースラインは押さえておく。
■「計画」でやっていること(コミュニケーション)
よく間違える。PMBOK読んでも「あたりまえ」のコトしか書いていないにもかかわらず、不正解多し。送ったメール=読んだものだと判断するのではなく、重要なら到達確認をするように、「あたりまえ」なことがあってもいちいち確認しながら再読するべ。
10.1 コミュニケーション計画
ステークホルダーの情報に対するニーズを特定する。つまり、誰が、いつ、どのような情報を必要とし、その情報は、誰が、いつ、どのように提供するかを決定する。プロジェクト成功の要因はコミュニケーションと言われるワリには実践されていないのが現実。実際、「優れたPMは勤務時間の90%をコミュニケーションに使う」というが、デスクにふんぞり返ったままじゃ、先が思いやられますな…
残念ながら現場では、PMI の真逆を行っている。うんこミュニケーション(うんこ+コミュニケーション)の実践例なら沢山あるぞ。
- メールを送った=読んだものと判断する:呼べば聞こえるのにメールばかりしこたま送りつけてくる。酷いのになると、「先日送ったあの件はどうなってますか?」(←本文ママ)と訊いてくる
- ノイズ入れまくり:ひょっとして意図を伝えたくないのかしらん、と勘ぐりたくなる。結論なしで「やったこと」だけをダラダラ書く。んなもんメーリングリストで流すな!
- こそあど言葉乱用:「あの件」「それについては…」で会話を成立させている。「ほら、アレだよアレ、わっかんないかなー」って、オレはオマエの番人じゃねぇ!
- 略すな!:略すということは、省略前の言葉を『お互いが』知っていることが前提。「TBを作りました」って何? Trackbackか? まさか、TeraByteなの? トロンボーン? Three quarterBacks か、テルビウムか、ブラウザのThunderbird か? ――結局テーブルを略したそうな―― その理由がイカしてる「TBの方が短くてカッコいいから」
コミュニケーションマネジメント計画書のアウトプットの中でも、「エスカレーションプロセス」に着目したい。よくある「体制図」は自組織の体制しか書いていないが、一工夫の余地あり。その隣に、顧客の体制図も記述するわけだ。名前が決まっていなければ空欄でもOK。そいつを顧客へ提示するわけだ。「これこれの情報レベルは、この担当が扱いますよ」というメッセージが伝わるはず。で、下位レベルでは解決できない問題は、マネジメントチェーンを通じて上へ持ち上げていくことが視覚化されるわけだ。このレベルを取り違えると、とんでもない悲劇か、全くの時間の浪費か、その両方になる。
■「計画」でやっていること(人的資源)
「人」も資源と一緒で、必要な時期に適切な人材を、必要な分だけ投入しなければならない。足りなきゃ持ってくるし、スキル不足ならトレーニングが必要(ってことはそのための期間もカネも必要)、いきなり投入しても馴染むのに時間がかかるし、他の足を引っ張るかもしれない。パフォーマンスが上がらないかもしれない。デマルコの傑作「デッドライン」には、その本質がこう書いてある。
・適切な人材を雇用する
・その人材を適所にあてはめる
・人びとの士気を保つ
・チームの結束を強め、維持する
(それ以外のことは全部管理ごっこ)
確かにその通りなんだけど、必要条件じゃぁないかと。他の要素ばかり目が行って、プロジェクトを実際に動かす「人」を疎かにしないように、という戒めとして読もう。
9.1 人的資源計画
要員マネジメント計画書を作成する。要員マネジメント計画書には、チームメンバーの調達方法、調達時期、プロジェクトからの離任基準、トレーニングのニーズと特定、報奨の計画、法令・規則への配慮、安全上の課題、組織の要員マネジメント計画への影響が記載されている。
――――――――――――――――――――――――――――――――
PMP試験対策【まとめ】
最近のコメント