何かを得るためには、他の何かを必要とするやつ。スコープを変更しようとするならば、時間、コスト、品質、リスク、リソース、顧客満足の全ての観点に照らし合わせて、再評価する必要がある。「スコープだけ拡張」は、ありえないPMが気を遣うべきものは、チームのパフォーマンス。PMの時間はチームビルディングに使うべしPMは「プロアクティブ」になるべき。問題の早期発見につとめ、プロジェクトの変化に気を配り、問題の予防に力を注げ。「そうは言っても...」という怨嗟に同意。「よくない兆候」は隠され、「進捗遅れ」は次週までに挽回しますと断言される(しかも繰り返し!)。するか?否定要素を受け入れるオープンな態度や、探偵ばりの聞き込み、進捗報告だけに留まらない打ち手の創出などを考えよ、ということやね「問題の対処」よりも、「問題の予防」に時間を使え。予防の一オンスは治療の一ポンドに優る。ほとんどの問題は、予めリスクマネジメント計画で洗い出して対処策を検討できる。「○○になったら→△△する」は最初に必ずやっておくこと。先送り先延ばしにするから、トラブルが顕在化したときにあわてるのだ。ダメなPMはこういう「だから言ったでしょ!」ってね。「問題になる可能性がある」と指摘するのなら、対処も一緒に考えろ("対処しない"と決めるのもアリ)チームミーティングで、進捗状況を話すな。進捗具合は他の方法で情報共有すべし。チームミーティングで話し合うべきテーマは、ずばり「リスク」。ダメなミーティングとしては、「○○機能が2週間の遅れ」→「どうするんだ!」→「来週までに回復します」というパターン。このPMIイズムに従うなら、第一声が、「○○機能の進捗遅れによる影響範囲は?」から始まり、「是正措置は△△の資源を投入します」と進む。そんなに上手くいくもんかと思うのだが、せめて「○週遅れたこうしよう」までは考えておくプロジェクトマネジメント計画における変更は、必ず変更管理と統合変更管理プロセスを経る。その中で影響範囲の検証と周知がオーソライズされるPMは組織のポリシーや組織内標準に沿った形でプロジェクトが運営されているか、保証しなければならないプロジェクトの構成要素に変更が加わるとき、真っ先に検証されるべきは、「品質」PMはプロジェクトで交わされる契約に通じていなければならない。PMP試験対策】シリーズについて。Prep"、通称Rita本の2本立て。PMBOKガイドを傍らに一連のエントリを「読むだけで合格する」ようなシリーズにするつもりだ。過去の記事は、以下のリンク先が入り口となっている。PMBOKガイドの古い版が元となっているが、「PMIイズム」「PM的思考」は学べる。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。