→プロジェクト管理
- 【「スゴ本」中の人が薦める】ITエンジニアなら知ってほしい。プロジェクトを炎上させないマネジメント術を身につける4冊 | レバテックラボ（レバテックLAB） 2023.1
- 『プロジェクトマネジメントの基本が全部わかる本』は、PM初心者向けの具体的なノウハウがまとまっており、「プロジェクトあるある」の初見殺しの罠は予習できる。なにより、何をどうしなきゃいけないかを、手取り足取り教えてくれる。
- 『アート・オブ・プロジェクトマネジメント』は、PM経験者向けにお薦めしたい。どのページを開いても上手く回すアイデアが詰まっており、「PMとは何か」の本質的な議論から、何かしらのヒントが得られることを請け負う。
- 『アジャイルプラクティス』は、PM、チームリーダー、エンジニアにとって、すぐに使える実践的なプラクティス集になる。どういう風に考え、口癖にして、習慣化していくと、上手く回せていけるかが身につく。拾い読みして、良さげなものを取り込んでいくのが効果的だろう。
- 『PMBOKガイド』は、オールマイティ―の究極の一冊といっていい。その分、抽象的に書かれているため、使い方に注意する必要がある。
- 危険察知に鈍感になってはいけない 2008.7.22
- ↓危険の兆候
- 見積もり会議やプロジェクト会議を早期に開催できない
- 状況報告の資料に定量的データがない
- 状況報告の資料を毎回（毎月）徹夜で作成している
- 発注先（協力会社など）の状況把握が行われていない
- プロジェクト内の問題が報告されない（他システムや顧客の問題ばかり）
- 大規模プロジェクトである
- 初めての顧客である
- 初めて取り扱う業務，技術である
- 必要ならプロマネに逆らってでも助けてと叫べ 2007.12.13
- PMOとして，プロジェクトマネジャの危険信号をどのように見極めればよいでしょうか。筆者の経験上，次の兆候のうち複数があてはまるようだったら要注意です。
- （1）プロジェクトメンバーがプロマネの指示に納得していない
- （2）指揮系統を無視して，末端の担当者にプロマネが直接指示する
- （3）顧客との関係が悪化している
- （4）メンバーからプロマネへの不平不満や悪口が噴出している
- （5）協力会社に対して無理難題を押し付けている
- （6）プロマネが何をしているのか，メンバーが分かっていない
- （7）プロマネ一人だけが何日も深夜残業や徹夜をしている
- PMP試験対策：リスクマネジメント
- 「事前に分かっているリスク」は、「何らかの準備をする」か「何も準備せず、監視する」のどちらかになるだけで、その違いは優先度による、ということ。
- 「優先度が高いにもかかわらず、分かっているのに何もしなかった」ことは、決してしないということ。
- 「このリスク登録簿にないリスクが発生したら、このお金を使う」という予算が、別に割当てられていること（←マネジメント・コンティンジェンシー予備）も重要。
- リスクは計画プロセスで全て明らかになるものではない。実行段階でリスクが発見されることもあれば、リスクが現実に発生してしまうこともある。
- 未知のリスクが発見された：リスク分析からのサイクルを回し、影響度・リスク対策とともに報告する
- 未知のリスクが現実に発生した：迂回策を取り、問題を回避する[p.355:PMBOK]
- 定性的リスク分析で高優先順位のリスクに対し、数値による等級付けを行う。要は、発生確率と影響度をカネに換算する。定性→定量の順に行うが、一度にする場合もある。
炎上プロジェクト／失敗プロジェクト(デスマーチ)への対応†
※ここでは主に火を噴いてしまったプロジェクトにどう対応するか、についての記事をまとめる。事前対策はプロジェクト管理そのものになる。
- 曖昧なプロマネ権限と責任がプロジェクトを炎上に導く 2014.1.27
- 営業と開発チームが分離した製販分離の開発体制の場合、時折「プロジェクトリーダ」に該当する役割を「プロジェクトマネージャー」って呼んでる
- 戦略的受注のため、営業の無理な案件受託のため、意図せずデスマにならざるを得なかったプロジェクトリーダは、炎上プロジェクトの責任を負うべきか、という話になるのですが、これはNoだと思います
- 例えば、プロマネが気を利かせてリーン開発とウォーターフォール開発を組み合わせて、顧客側の仕様検討のブレに対するリスク回避しようとしても、そもそもリーン開発を選択できる権限が「プロマネ」に与えられてないわけです。
- これじゃあ、開発手法で工夫してプロジェクト炎上を防ぐなんて夢のまた夢です。
- デスマーチ突入時の打開策 2007.11.22
- いったん冷静になりましょう。そしてミーティング
- 各スタッフの残タスクを見やすいように整理整頓
- スケジュール見直し。安易な延期提案はダメ
- プライオリティの低いタスクを放置しない
- エンジニアの周りをうろちょろしない
- 火を噴いてからPMOを入れても遅い？ 2008.2.27
- 火消し部隊を投入しなければならないと気付くタイミングでは，「時すでに遅し」となっている可能性が非常に高いものです。火消し部隊の役目が，プロジェクトを終わらせるための落とし所を模索する活動に変わっていることも多々あります。
- PMOはプロジェクトの管理事務部隊ではなく，プロジェクトの生産性を向上させるための組織です。プロジェクトの開始当初からマネジメント・プロセスを整備し，プロジェクトを円滑に推進できるように準備することを，世の中のプロジェクトマネジャに推奨します。
- この考え方は，現場のプロジェクトマネジャだけでなく，組織のマネジメント層の方々が理解しないと，なかなか受け入れられにくい
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
