課題管理をしなかった話
プロジェクトに関わらず、仕事をしていれば進捗上の障害が大なり小なり発生する。進捗上の障害と認識するのは、段取りや手順で想定していたことと違うことを事象として捉えたからである。
多くの場合は、そうした進捗上の課題を認識するが、わざわざ課題を管理しようとしない。個々の裁量の中で取り扱う。
一人で行なっている仕事であり、後続工程がなければそうした課題を放置していてもなんら影響はしないため、しばしば放置される。
後続工程があったり、複数の人員で作業を行い、その課題が他者に影響する場合は、課題管理と称して管理表やチケットに記録し、課題解決までトレースされる。
プロジェクトマネジメントにおいて、プロジェクトを成功させるためのテクニカルで不可欠な要素に『課題ログ』が挙げられている。
調査によると、有能なプロジェクト・マネジャーが一貫して示すいくつかの重要なスキルには 次が含まれるが、これらに限定されるものではない。 ●自らがマネジメントする各プロジェクトのためのテクニカル・プロジェ
不可欠な要素に焦点を当てる。このことは、容易に入手できる適正な生成物を確保するのと 同じくらいシンプルである。このリストの上位にあるのは次のとおりである。■プロジェクトの重要成功要因
■スケジュール
■ 選択された財務報告書
■課題ログ
引用 PMBOK 6th
プロジェクトであるから、複数人数のプロジェクトチームでの活動を前提として、ステークホルダも考慮して課題はログとして管理することの重要性を記しているのだろう。
実際の現場でも、QCDSで何かしら失敗しているプロジェクトやオンゴーイングなプロジェクトでおかしい状態になっているプロジェクトでは、しばしば課題管理がなされていないか放置されていることが多い。
複数の事象とプラクティスからは課題管理をしなくても良いとは到底言えない。
あるプロジェクトは短期で関係者が多いものだった。コンサルタントを入れ、コンサルタントチームとしては課題管理をしていた。一方、エンドユーザのPMの立場では課題をすることのリソースを確保することが難しい状態だった。
それで、どうしたか。
課題にしないことにした。全て、ToDoとして振り分けることにした。
どういうことかというと、課題になる前に、作業計画として振り、計画どおりに進めた。コンサルチームとして認識する課題はほぼコンサルの課題である。
エンドユーザ側のPMとしては、関係者が分担する作業は次回か次回の前の指定日までに対応するように指示することにした。その際に、実現可能なスケジュールであるかと最遅日を押さえ、その前には片付くように促した。
あとは対応を待つだけである。もちろん、指定日までに別件で会う機会があれば、進捗を尋ね、裏を押さえる手間を掛けるだけでほぼ確実に進捗するのである。
大したことではない。
少しの手間をかけることで、課題管理の作業を無くしただけである。まあ、これも関係者が全て同じ方向を向いて要られたからできたことではある。
