なぜ停滞してしまうのか
プロジェクトは組織の枠組みを越え、
期限を定めて取り組むものです。
プロジェクト体制を組み、役割を設定しても、
上手くいくチームといかないチームが
出てくるようになります。
言わずもがな、
上手くいかないチームには、
タスク完遂への力量不足が生じている為、
チーム外の協力が必要になります。
しかしながら、
実際には下記の理由から協力を得られず、
停滞してしまうことがよくあります。
・そもそもタスク化していない
・タスク停滞を報告していない
・タスク停滞と認識できていない
・停滞の真因を特定できていない
・停滞解消の相談をしていない
・停滞解消の施策案が不適切
つまり、
上記はいずれも停滞してから、
判明してくる事柄と言えます。
従って、
停滞してからの対応ではなく、
停滞する前に対応相談できるのが、
望ましい姿であり、
そのような進捗確認の場を
如何に作るかが重要となります。
特に、
協働する組織の枠組みが大きいほど、
上記のコミュニケーションプランが
プロジェクト成否に関わる度合いも
高まってきます。
やばくなる前に・・・プロジェクト推進の三種の神器
進捗確認の場作りの為には、
報告資料として下記3点が必須であり、
私は三種の神器と呼んでいます。
課題一覧
週次報告書
多くの場合は用意されていますが、
未更新だったり、軽視・過信するが故に
形骸化する場合が非常に多く、
使いきれていません。
これからその重要性について
一つずつご紹介します。
①WBS（Work Breakdown Structure）
WBSとは、
大まかな工程を細かな作業に分解し、
各作業の納期や役割を設定した帳票です。
この帳票の追加、更新を日々管理し、
関係者に共有していくことが
非常に重要な推進者の役割となります。
というのも、
大まかな工程から作業に分解する為、
スケジュールの遅延に直接影響する
作業（クリティカルパス）を発見し、
速やかに対応の議論を開始でき、
それ自体が円滑なプロジェクト進行に
直結していくからです。
また、
この帳票にある工程や作業における
抜け漏れの有無も関係者によって
チェックすることができますので、
各工程や作業の担当者への
支援にも直結させることができます。
一方、WBS作成ツールですが、
私はGoogleスプレッドシートで
作成、管理することが大半です。
以前はExcelでしたが、
Googleスプレッドシートに比べて
更新と共有にタイムラグが生じたり、
更新した版の管理が煩雑なので、
ほぼ利用しなくなりました。
SaaS（Software as a service）
と呼ばれるレンタルサービスとして
プロジェクトマネジメントツールも
出てきていますが、
ライセンス料やカスタマイズなど、
費用や使いやすさの面で、
あまり利用機会がありません。
必須情報項目としては下記です。
・大カテゴリ（概念レベル）
・中カテゴリ（工程レベル）
・小カテゴリ（作業レベル）
・終了期日（予定）
・開始期日（予定）
・終了期日（実績）
・開始期日（実績）
・担当者（一人を設定）
・状態（未着手、着手中、完了、中止）
・状態理由
この程度で進捗管理は十分に可能です。
やることを洗い出そう②課題一覧
日々のプロジェクト活動の中で、
想定課題以外に想定外の課題も
数多く積み上がってきます。
プロジェクトメンバーの
記憶だけでは処理しきれない為、
課題一覧として記録すれば、
対応漏れの防止や経緯の振り返りに
活用していくことができます。
しかしながら、
この管理がされていない場合を
よく目にします。
メールや会議で課題化されるものの、
一覧として追加、更新、管理されず、
対応漏れや対応スルーが起きます。
人の記憶は曖昧になりやすいので、
役割や責任の所在を明らかにして、
できない理由、停滞している理由を
公開、協議できる場が必要です。
上手くいかない事を報告するのは、
心理的負荷も大きくなる為、
課題化自体を回避することで、
順調とミスリードさせる場合も
少なくありません。
そのような行動を予防する為にも、
課題一覧管理は責任追及ではなく、
相互補完を目的とするという主旨を
予めプロジェクト参加者の中で、
認識合わせすることが肝要です。
必須項目としては下記です。
・課題番号
・課題内容
・起票日
・起票者
・対案
・回答者
・回答日
・状態（未着手、着手中、完了、中止）
・状態理由
課題は分担した方が簡単③定期報告書
組織を跨いで協力を得る上では、
プロジェクト内の上位層への
共有が不可欠になりますが、
WBSや課題一覧は担当者間で、
共有するには最適なのですが、
細かすぎて理解されません。
また、
定期的な報告無しに相談しても
断片的且つ局所的な論点では、
全体感が掴めず、理解を得にくい。
従って、
プロジェクトの理解を求める上で、
定期的な進捗報告が重要です。
というのも、
起きてからの報告は「弁解」
だからです。
「説明」は透明性高く進める為、
信用作りの助けになりますが、
「弁解」は不透明に進めた結果なので、
信用作りにはつながりません。
また、定期的な報告は、
毎週、隔週、毎月とありますが、
プロジェクトの立ち上がり時期は、
関係者の理解が未形成なので
高頻度の実施が求められますが、
ある程度、理解が形成されれば、
自ずと頻度は下がっていきます。
報告書の内容としては下記です。
・全体スケジュールの遅延有無
・遅延理由
・リカバリー案と再設定期日
・進捗に影響する対内課題
・進捗に影響する対外課題
・上記各項目の詳細説明
植物は、
日当たり良く、水やりをしないと
育っていきません。
勝手には育ちません理解や信用も、
透明性高く、情報発信しないと、
築いていくことができませんので、
日々、定期的に進捗共有する場合を
積極的に作っていきましょう。
問題と課題の違い
最後にプロジェクトにおける
「問題」と「課題」の違いについて
ご紹介します。
課題とは、あるべき姿への解消すべき乖離
この二つは混同しやすく、
難易度も大きく異なりますので、
適切に認識した上で、
それぞれに適した対処を選択し、
進めていく必要があります。
プロジェクトにおける問題とは
まず、「問題」についてです。
「問題」には原因がありますから、
なぜ発生しているのかを深掘り、
その原因を無くす対処が必要です。
良くあるケースとして、
直感的に浮かんだ対策から
原因を特定していくアプローチが
無意識的に取られています。
が、これは手段が目的になっていて、
問題解消には至りません。
大抵、問題の原因を突き詰めると、
ルールや制約条件に行き着きます。
例えば、人がミスした場合は、
忘れや見逃しを原因にしがちですが、
本来は、システム化してない、
業務を無くせない事が原因です。
このような捉え方をしないと、
改善止まりに終わってしまい、
改革に到達しにくくなります。
もう問題が起きないようにプロジェクトにおける課題とは
一方、「課題」は、
「あるべき姿への解消すべき乖離」であり、
「問題」と違い、原因がありません。
つまり、
新たにハードルを設定するので、
超える為の必要な条件を想定し、
必要な準備を進めていく事になります。
乗り越えて、更なる高みへ従って、
課題解消に向けては下記が必要です。
・現状の可視化、分析
・外部環境分析
・あるべき姿の具体化
・仮説の設定、検証
原因の特定は深掘りですが、
課題の設定は視野を広くした上で、
各論点の深掘りを必要とする為、
より難易度が高いと言えます。
従って、問題と課題を区別せず、
同じような対処をしていくと、
結果は得られず、右往左往します。
今、自分が取り組むことが、
問題か、課題か正しく捉えましょう。
何を考えるべきなのかを整理した上で
取り組む事ができれば、手戻りなく、
最短距離で結果を導く事ができるはずです。
