プロジェクト/課題管理
プロジェクトをスケジュール通りに進めることを阻害する要因のことで、ここでは特に作業に落とし込めていないものと定義する。
概要 †
課題は予定されたタスクを遂行する上での障害となるものがその大半であり、未解決課題の数とプロジェクトリスクは正比例する。
重要課題ほど早期の解決が必要であり、期日と解決者を割り当て、遅延の影響を明確にし、進捗を確認し、期日を越える前に対策を打つ、という管理を徹底すべきと考える。
上記の「作業に落とせていない」ものについて、WBS上に定量的に表現できてさえいれば単なる作業に過ぎず「やるだけ」なのだからクリティカルでもなんでもない。
何がやばいかというと定量的に把握できない状態であるということがやばいのだ。スケジュールのリカバリも顧客への説明も、見通しを立てることができていなければ、どうにもならない。
目的 †
進捗管理と品質管理より、問題点を顕在化させ、プロジェクトの遂行に支障を来たすテーマを検討し、対策の立案・実施・解決状況の管理を行う。
これにより、作業進捗・作業範囲・成果物の品質に影響を及ぼす問題点に対し、各位の認識を共有し、適切なアクションを即時に繋げることで、プロジェクトの円滑な推進を図ることを目的とする。
当然ながら、これを達成するためには、関係者総員が管理方法と手順を理解する必要がある。
定義 †
前述の通りプロジェクトの目標達成を阻害する要因であり、記載者のみでは解決不可能なものを課題とする。
この定義に照らし合わせると、ある特定のチームまたは個人に問い合わせれば即時に回答が得られる問題は課題管理対象外であるが、タスク・個人レベルの作業としてすでに識別されているTo-Doについても、単に埋もれてしまったり記載者が認識する以上に大きな範囲である可能性があるため、担当者と納期が規定されていないことを条件に対象に含めるべきと考える。
つまり、これが作業に落とし込めていないものを意味する。
分類 †
課題は、具体的な解決に向けて担当や内容を詳細化するため、関係者と影響範囲の規模に応じて管理するべきであり、以下のレベルが挙げられる。
ただし、小規模プロジェクトにおいては下記の分類は冗長かつ効果的でないことは多く、Priorityという軸でA~C程度の評価で必要充分であることは補足しておく。
統合課題 †
プロジェクトチーム内で意思決定が困難な課題、もしくはプロジェクトの進捗に多大な影響を及ぼす重要事項。
マネージャ層がステコミにて、ユーザサイドの判断を仰ぐ内容。
プロジェクト課題 †
プロジェクト全体、もしくはチームを跨って解決すべき業務上、システム上の課題。
マネージャーが主体となって管理を行い、課題解決の責任を担う。プロジェクト進捗会議において課題の新規発生状況、及び既発生課題の解決状況を報告し共有を図る。
チーム課題 †
チーム内で閉じた課題であり、チーム内で解決すべき業務上あるいはシステム上の課題。
チームリードが主体となって管理を行ない、課題解決の責任を担う。
但し、チーム共通課題に分類される課題でも、作業に与える影響が大きいなど重要性の高いものは、チームリーダーの判断に基づきプロジェクト共通課題として管理する場合もある。チーム進捗会議において課題の新規発生状況や既存テーマの解決状況を報告/共有する。
コメントはありません。 Comments/プロジェクト/課題管理?