知者は水を樂しみ、仁者は山を樂しむ

お城、読書、プロジェクトマネジメント。ユーザ系IT企業 中間管理職のつれづれ

プロジェクトリカバリのコツとヒント(4)

プロジェクト診断後、リプラン

特にトラブルプロジェクトでは、当初計画と実態は乖離していることがほとんどです。以後のリカバリのために、リプラン、リスケジュールをする必要があります。なお、「リスケ」は便利な言葉なので、多用するとプロジェクト内外に対して、計画的に進めていない印象を与える可能性が高まります。計画を立て直す「リプラン」の方が建設的に受け止められると思います。


特にトラブルプロジェクトの場合は、すでに計画が破綻していることがあります。リプランにあたっては、まずゴールを再設定するところから始める必要があります。

 

最低限守らなくてはいけないゴールは?

QCDで言えば、納期が必達なのか、すべての要求事項を満足することが至上命題なのか、品質を落とすことが許されないのか。QCDすべてを実現することは難しい状況だと考えられますので、優先順を再定義して、到達すべきゴールを再設定してから、全体のスケジュールを決めていく方法が良いです。

  1. ゴールとマイルストーンの設定
  2. ゴールから逆算したスケジュールの設定
  3. 枠をはみ出さないようにスケジュールをブレークダウンする
  4. 全員で共有する(貼り出す、いつも見せる)

 

プロジェクト計画時点、開始時点では、タスクの積み上げ式でスケジュールが作成されていると思います。WBSに分解され、個々のタスクに納期が割り当てられています。積み上げ式の注意点は、各メンバーが見積もった場合、バッファが組み込まれているかどうかが不明瞭になりがちなことです。


クリティカルチェーンエリヤフ・ゴールドラット著)」によれば、

  • 自分の経験に基づいて設定されるバッファは、長くなる傾向
  • フェーズごと、階層ごとにかかるマネジメント時間は、見過ごされる傾向がある
  • メンバーは、バッファがカットされるのを見越して水増しする。

という特徴があるそうです。

 

また、バッファは往々にして無駄遣いされがちで、その理由としては

  • 学生症候群(最後まで取りかからない)
  • 作業の掛け持ち
  • ステップ間のプラスマイナスで消えてしまう(早く完了したステップがあっても、全体として短縮されない)

があるとのことです。

 

したがって、バッファはタスクごとに設定するのではなく、スケジュールの最後にまとめて確保するようにした方が良いです。想定外の事象は必ず起きると想定しておいた方が無難です。

 

プロジェクト運営ルールを見直す

リプランにおいては、同時に、プロジェクトの運営方法について見直すべきところを改善します。特に会議体はプロジェクト活動に占める割合も多いので、必要性、目的や主催者、出席者、議題、開催頻度などを再考した方がよいでしょう。
機能していない定例会議は廃止しましょう。例えば、以下のような会議には無駄が含まれています。

  • 開催スケジュールが決まっていない
  • 参加者が多すぎる
  • 会議の時間が長すぎる
  • 議題が決まっていない
  • 会議が終わった時に何も決まっていない

日本人は開始時間に厳しいが、終了時間にルーズ、という特徴があるそうです。ファシリテーター、タイムキーパー役を準備しておくと効果があります。

 

一方、やると決めた定例会議は絶対にやり切ることが重要です。よくある欠席理由が「お客様との会議が入った」というもの。お客様優先と考えてのことかもしれませんが、プロジェクトの会議活動もお客様のためのもの。なぜその時間に別の設定したのか、よく確認する必要があります。ただ、どうしても時間が合わないのなら、定例会議の時間を柔軟に変更することも必要です。

 

そのほか、プロジェクトのルールを見直し、正しいと思われる新しいルールを決めます。メリットのないルールは無くしましょう。例えば、社内報告用の資料をわざわざ作ることや、ビジネスチャットに「お疲れ様です」「承知しました」は不要として、いいね!ボタンなどで代用することです。

 

トラブルプロジェクトは勤務時間がルーズになりがち。統制が取れていない状況は即時、正さなくてはなりません。朝会を再設定してリズムを作り直しましょう。(リズムについては次章で再掲)

 

ルールの例

  • 出社時間、退社時間、遅刻または早退時の連絡ルール
  • 座席表、連絡先(電話、メールアドレスなど)
  • 成果物のネーミングルールおよび格納場所
  • 会議体のルール(時間、場所、議事録など)

テンプレートの例

  • 進捗確認シート
  • 成果物テンプレート(要件定義書、設計図など)
  • 問題発生時の管理ルール(データベースなど)
  • プロジェクト辞書(用語説明など)

 

ところで、キックオフミーティングはどんな状況であっても重要なイベントです。

通常のプロジェクトを開始時点はもちろん、途中でプロジェクトを引き継いだを場合であっても、プロジェクトチームの心理的ダメージを軽減して、モチベーションを切り替えるきっかけになります。

 

通常のキックオフミーティングでは、計画、スケジュール、体制、会議体、ルールなど事務的・形式的な内容が中心になりますが、トラブルプロジェクトでは、プロジェクトの本来の意義、目標を再認識したり、「こうすればできる」という前向き、未来形、私たち(We)を主語にしたメッセージがとても重要になります。

プロジェクトチームの自己効力感を高めていきましょう。

Copyright birdie-chance92 All Rights Reserved.