【感想】プロジェクトのトラブル解決大全　小さな問題から大炎上まで使える「プロの火消し術86」

非常に良い。
１章の01に、"トラブル対応のファーストステップは「腹をくくる」こと。「自分は被害者だ」と思ったらそこで負け"と書いてあるのが素晴らしい。
内容の７割はトラブル時に限らず、通常のプロジェ…クト管理でも実施するべきことなので、炎上案件に関係なく参考になる内容。続きを読む

プロジェクト管理のための実践的なノウハウ・テクニックが詰まっている。
教科書的な話というか理想論的な話ではなく、筆者の経験を元にした対処法という仕立てなので、参考にできる術は多いと感じる。

・成否は「最初に腹をくくれるかどうか」で9割決まる。
　〇：腹をくくり覚悟を決めている
　×：いざという時の逃げ道を作っている。(「自分は被害者だ」と思ったらそこで負け、他責にならない)

・「トラブ…ルの原因は何だと思う？3つ教えて」、仮説を考えていないと答えられない。

・犯人探しが無意味な理由
　(1)犯人を間違ってしまう可能性が大きいから(色々な人の主観は正しいとは限らない)
　(2)たとえ犯人がわかっても、その人にだってプロジェクトで活躍してもらわないといけない

・ビジネスパーソンが仕事の期限を守る動機は２つだけです。
　(1)プロとして期限には必ず仕上げる、と言うモチベーション
　(2)期限を過ぎると怒られるから、遅れないようにやろうという気持ち(9割の人がこちら、それを考えると、期限を超えたときには指摘をしないといけない、ということが分かると思います。)

・長年の炎上経験から、「すみません」「申し訳ありません」という言葉を安易に発しなくなった。理由はシステム開発の契約形態にあり、自分たちの品質などに落ち度を認めてしまうと、それはどんなに時間とコストがなかったとしてもやらざるをえない状況においこまれてしまう可能性が高くなる。

・ただし本当に実害を伴う問題が起きたときには、すぐに謝る。原因は推測しない。原因がわからないうちに原因の可能性にまで言及してしまうと、余計なアクションを課せられることがあるから。この時真面目な人ほど「いつまでには報告します」と言い添えなくては、思うものですが先走って期限を切ると自分たちの首を絞めることになる。期限を求められなければ期限を宣言せずに「追って報告します」といって済ませますし、「報告します」と言わない事もあります。やらなくてもい仕事は増やさない事。

・できるリーダーはみんな姿勢がいい続きを読む

プロジェクトに対するマインド、管理すべき内容、リーダーシップについて、プロジェクトを成功させるための幅広いTipsがまとめられた本。
プロジェクトに関連するフレームワークの説明ではなくそれをどう使うか…が述べられていて実践的であった。続きを読む

PMPとか他のプロジェクト管理の本とか読んだが、この本が最も実践的な内容である。
私の中だけなのかもしれないが、プロジェクト管理の名著と言ってよい。

炎上プロジェクトは避けて通りたいが、避けきれなかった場合はこの本を読み直そうと思う
判断ではなく決断というのはリーダーとして常に心掛けておきたいポイントだった

プロジェクトの把握
　プロジェクト計画…書
　体制図
　　人数、チーム数
　　　メンバースキルの可視化
　　　　設計
　　　　プログラミング
　　　　業務スキル
　　　　マネジメント
　　　　リーダーシップ
　　リーダー、キーマン
　　　懐刀になる人
　　　トラブルメーカー
　　　　対応時は影響力を無視しない
　　指揮命令系統
　課題管理表
　　スケジュール、担当者
　　課題収集プロセス
　　優先度判断
　　　重要度、緊急度、難易度、効果、コスト、時間
　進捗報告資料
　
　質問項目
　　PMBOKの知識体系ベース
　　QCDベース
　　仮説を立てる
　　　トラブルの原因は？
　　　　問題、原因、対策
　　　　　あるべき姿と現実のギャップ
　　　　　マトリクスで検討
　　　　　　QCD、機能、開発フェーズなど
　　タテヨコ
　　　具体と抽象、類似
　　事実の確認
　　　なぜそう思うのか
　　　　原因は何だと思うか
　　　推測の場合は判断基準は
　　　　どの資料を見れば確認できるか
　　わかっていること、わかっていないこと
　　　軸毎に洗い出し
　　　　システム調査なら機能毎、など
　　できない理由の精査
　　　どうすればできるようになるのか
　　　　制約を外す方法は
やらないことを決める
　リソースの集中
スケジュールはゴールから逆算
　10％ほどのバッファー(見積もりの-10%で計画)
　バッファーはタスク毎に乗せない
　　メンバーからの見積もりは詳しく精査
　　スケジュール全体でバッファーを持つ
　1タスクは5営業日以内
　　担当者は必須
　　複数人での担当になる場合はタスクを分ける
会議
　頻度、議題、参加者が適切か
　　議事録、アクションリスト
　議論の活性化
　　各自に意見を求める
　準備不足の場合はリスケ
　　スケジュールは決める
プロジェクトの意義を共有
チームのルールは守らせる
　都度なぜ守らないか聞いたりして守る雰囲気を作る
最低限の管理
　作業管理、進捗管理、課題管理
　　作業遅延
　　　原因、対策、リカバリ予定日を確認する
　　課題
　　　内容は明確に分かりやすく
　　　担当者を決める
　　　　連名にしない
　　　期限を決める
　　　　最低限の日数で
　　　起票者は担当にしない
朝会
　前日の状況確認
　　問題、課題の状況確認
　　共有事項確認
　当日の予定確認
　課題表確認
属人性排除
　手順、プロセス定義
　テンプレート用意
　ツールでの自動化
マイクロマネジメント
　期間限定で行う
　確認頻度を上げる
　　朝会、夕会
　確認内容を細かく
　　数字での進捗確認からタスク内容の確認へ
PDCA
　PDとCAのマトリクスで考える
　　計画、実行内容がどうだったか
　　改善点をもとにしたアクションプラン
ガス抜きヒアリングでは約束はしない
　課題を理解したので検討する旨を伝える
　　共感はするが解決の約束はしない
リーダーシップ
　9割ポジティブ
　　諦め癖の言葉に注意
　　メンバーと話し合う
　支えになる言葉を持つ
　　転ぶときも前のめり
　責任を持つところと持たないところの線引きをしておく
　チームに良い緊張感をもたせる
　　メンバーの成果、仕事ぶりに厳しく
　　プロジェクト成功のための妥協をしない続きを読む