→プロジェクト管理

#contents

*リスクマネジメント一般 [#db9a1510]
-[[奇妙な態度で仕様変更に抵抗するとき>http://el.jibun.atmarkit.co.jp/genmaicha/2010/10/8-bb31.html]]

-[[問題点やリスクの把握を怠ってはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080702/310036/]] 2008.7.24

-[[危険察知に鈍感になってはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080702/310027/?ST=pm&P=1]] 2008.7.22
--↓危険の兆候
--見積もり会議やプロジェクト会議を早期に開催できない
--状況報告の資料に定量的データがない
--状況報告の資料を毎回(毎月)徹夜で作成している
--発注先(協力会社など)の状況把握が行われていない
--プロジェクト内の問題が報告されない(他システムや顧客の問題ばかり)
--大規模プロジェクトである
--初めての顧客である
--初めて取り扱う業務,技術である

-[[必要ならプロマネに逆らってでも助けてと叫べ>http://itpro.nikkeibp.co.jp/article/COLUMN/20071211/289292/]] 2007.12.13
--PMOとして,プロジェクトマネジャの危険信号をどのように見極めればよいでしょうか。筆者の経験上,次の兆候のうち複数があてはまるようだったら要注意です。
---(1)プロジェクトメンバーがプロマネの指示に納得していない
---(2)指揮系統を無視して,末端の担当者にプロマネが直接指示する
---(3)顧客との関係が悪化している
---(4)メンバーからプロマネへの不平不満や悪口が噴出している
---(5)協力会社に対して無理難題を押し付けている
---(6)プロマネが何をしているのか,メンバーが分かっていない
---(7)プロマネ一人だけが何日も深夜残業や徹夜をしている 

-[[トラブル削減のための原則17箇条>http://enterprisezine.jp/article/detail/181]] 2007.10.25

-[[PMP試験対策:リスクマネジメント>http://dain.cocolog-nifty.com/myblog/2007/01/pmp235__39d7.html]]
--「事前に分かっているリスク」は、「何らかの準備をする」か「何も準備せず、監視する」のどちらかになるだけで、その違いは優先度による、ということ。
--''「優先度が高いにもかかわらず、分かっているのに何もしなかった」ことは、決してしない''ということ。
--''「このリスク登録簿にないリスクが発生したら、このお金を使う」という予算が、別に割当てられていること''(←マネジメント・コンティンジェンシー予備)も重要。
--リスクは計画プロセスで全て明らかになるものではない。実行段階でリスクが発見されることもあれば、リスクが現実に発生してしまうこともある。
--未知のリスクが発見された:リスク分析からのサイクルを回し、影響度・リスク対策とともに報告する
--未知のリスクが現実に発生した:迂回策を取り、問題を回避する[p.355:PMBOK]
--定性的リスク分析で高優先順位のリスクに対し、数値による等級付けを行う。要は、発生確率と影響度をカネに換算する。定性→定量の順に行うが、一度にする場合もある。

-[[リスクマネジメントの考え方を知る>http://itpro.nikkeibp.co.jp/article/lecture/20061114/253688/?ST=lecture&P=1]]


*失敗プロジェクト(デスマーチ)への対応 [#n5fa9826]
※ここでは火を噴いてしまったプロジェクトにどう対応するか、についての記事をまとめる。事前対策はプロジェクト管理そのものになるので。
最大にして唯一の対策は''そもそもデスマーチを発生させないこと''であるのは言うまでも無い。

-[[デスマーチの行進の仕方>http://getlife.hateblo.jp/entry/2014/03/03/083529]] 2014.3.3

-[[山本一郎氏が語る、プロジェクト炎上のメカニズムと鎮火法>http://www.atmarkit.co.jp/ait/articles/1304/16/news105.html]] 2013.4.16

-[[プロジェクトの遅れを取り戻す方法10選>http://japan.zdnet.com/sp/feature/07tenthings/story/0,3800082984,20384523,00.htm]] 2008.12.2

-[[デスマーチ突入時の打開策>http://blog.livedoor.jp/ld_directors/archives/50833805.html]] 2007.11.22
--いったん冷静になりましょう。そしてミーティング
--各スタッフの残タスクを見やすいように整理整頓
--スケジュール見直し。安易な延期提案はダメ
--プライオリティの低いタスクを放置しない 
--エンジニアの周りをうろちょろしない 

-[[火を噴いてからPMOを入れても遅い?>http://itpro.nikkeibp.co.jp/article/COLUMN/20080225/294718/]] 2008.2.27
--火消し部隊を投入しなければならないと気付くタイミングでは,「時すでに遅し」となっている可能性が非常に高いものです。火消し部隊の役目が,プロジェクトを終わらせるための落とし所を模索する活動に変わっていることも多々あります。
--PMOはプロジェクトの管理事務部隊ではなく,プロジェクトの生産性を向上させるための組織です。プロジェクトの開始当初からマネジメント・プロセスを整備し,プロジェクトを円滑に推進できるように準備することを,世の中のプロジェクトマネジャに推奨します。
--この考え方は,現場のプロジェクトマネジャだけでなく,組織のマネジメント層の方々が理解しないと,なかなか受け入れられにくい

-[[デスマーチの構造@ヨードン>http://www.atmarkit.co.jp/im/carc/serial/lookingfor15/lookingfor15a.html]] 2007.3.2

-[[デスマーチ:http://iwatam-server.dyndns.org/software/devintro/deathmarch/deathmarch/index.html]] by Iwatam

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS