もっとも、キットＰＭはやるべきことが山積みでなかなか休んでいられないのですが、気ばかり焦って効率が上がりません。辛いものです。
前回からプロジェクトにおける「問題解決へのアプローチ」について考えています。
プロジェクトを実施していると、問題発生とその対応がマネジャーに求められるのは必須となります。中には一切トラブルが発生しないプロジェクトもあるのかもしれませんが、不幸にもキットＰＭは未だ経験したことはありません。
であれば、積極的に問題解決の手法を考えることが大切なのは、皆さんにも同意いただけると思います。
前回問題解決の手順として、① 問題発生の認識 ② 問題原因の追究 ③ 対策の検討 ④ 対策の実施を上げました。これに加えて、⑤ 対策の効果の判定という５つの工程が必要となります。
特にプロジェクトとそれ以外の問題解決手法には、多少の違いがあることを理解することが重要となります。
前回も書いたように、状況によっては何も対策を講じないことがベストチョイスだったりするのです。
では順を追って実際の手順について考えてみましょう。
まずは、問題点の認識です。通常実施プロセスにおけるプロジェクトマネジメントのメインの作業は進捗度合いの計測です。
この方法については、分割されたタスクの実施状況を予定と実際で比較するという、ごく一般的なですので、プロジェクトに関わったことがある方なら誰もが経験することだと思います。
また、プロジェクトの問題のほとんどがその結果として進捗に影響します。ですから、進捗度合いを正確に測ることが問題発生をとらえる近道となります。
ただし難しいのは、単純に今現在の進捗の良し悪しを判定するだけでは「正確」な進捗の把握とはならないということです。
そのためにタスクの重要度により進捗の「遅れ」がプロジェクトに与える影響を判断することになります。つまり、重要な一連のタスクの繫がりを抑えてそのラインに属するタスク（クリティカルパスのことですね）の進捗を、特に重要ととらえマネジメントすることが広く行われています。
ところが、クリティカルパス以外のタスクの進捗が遅れることで、クリティカルパス自体が変動することが発生し得るのです。つまり、日程に余裕があってそれほどスケジュールに影響がないと考えられていたタスクが思いの外遅れることで、クリティカルパス上に移動してしまうわけです。
ということは、プロジェクトの進捗にしたがって、各タスクの遅れをどうとらえるかを、マネージャーは意識することが必要だということです。これはすべてのタスクの進捗を、等しく把握するということであり大きなコストが必要になることから、ＰＭにとってはかなり難しいハンドリングとなります。
これに対処するには、ＴＯＣのバッファマネジメントが有効な回答となります。バッファマネジメントについては、別の機会に詳しくご紹介することにします。
問題の存在を認識することができれば、次はその原因を追究することになります。次回はこの考え方について考えて行くことにします。