（出所：123RF）
連載
炎上するプロジェクト そのときどうする？
目次
-
ダメージ広げる「二重帳簿」 問題を共有し解決に当たる
［最終回］QCDのトラブル
プロジェクトで問題なのは、遅れが発生することそのものでなく、遅延が可視化されていないことだ。関係者の介入を恐れて本音と建前を使い分ける「二重帳簿」状態になれば、問題解決は絶望的になる。言いにくいことでも本音で問題を共有し、プロジェクトチーム全体で解決に当たろう。
-
体制図と役割が不一致 管理タスクは階層で明確化
［第5回］役割定義・分担のトラブル
体制図に入っていない人の発言が、プロジェクトの進行を左右してトラブルを招く。単にハコを並べてラベル付けしただけの体制図で、役割分担が不明確だからだ。管理タスクは階層化して分割し、それぞれの役割を定義して文書化しよう。
-
ユーザーとの対話に問題 スキルを見極め対策を打つ
［第4回］体制・要員のトラブル
プロジェクトのリソースは潤沢でない場合が多く、体制や要員の問題がトラブルを招くリスクがある。プロジェクトのメンバーが想定した役割を果たせない場合、交代も視野に入れた対策が必要になる。PMOなどのプロジェクト支援組織は、邪魔な存在と考えるのでなく、味方につけることが大事だ。
-
改善要望がパワハラに発展 管理者間で対策を協議
［第3回］立場・力関係のトラブル
プロジェクトの完遂という目的は一致しているはずなのに、立場や力関係の違いがトラブルを招く。個人対個人の対立がハラスメント問題にまで発展し、プロジェクトの進行を阻害してしまうこともある。感情的な対立やリスクの押し付け合いは即刻やめ、本来の役割分担を取り戻す策を打とう。
-
要求追加が止まらない 方針を実務に落とし込む
［第2回］スコープ・実装方法のトラブル
コストや期間が限られているシステム化には割り切りが必要だが、人は「現状」に固執しがちなもの。特に、パッケージソフトウエア導入プロジェクトでは、機能のミスマッチが炎上の火種になりやすい。目的・目標を再確認して方針を定め、方針を実務に反映できる指針とプロセスに落とし込もう。
-
責任者の退職で状況一変 一方的主張を排除し再合意
［第1回］顧客・発注者とのトラブル
プロジェクトの最大のリスクは、顧客や発注者とのトラブルにある。立場が異なるステークホルダーを適切にコントロールするのが難しいからだ。解決への動きを先送りせず、“先手必勝”で毅然と対応しよう。
