WBSのメンテナンスで効率化
WBSのメンテナンスをして再利用できるようにする
漏れていた作業項目があれば後で付け足します。分解する必要がないと思っていた作業項目を必要にせまられて分解した場合は、理由と共に分解した作業項目で残しておきます。
プロジェクトが終了した時、メンテナンスされたWBS（作業分解図）がITベンダーにとって財産になります。同じようなシステム開発依頼がきた時、どれぐらいの作業項目があり、どんな人員手配をしなければならないか工数がどれほどかかりそうか、WBS（作業分解図）から把握できます。前回、漏れた作業項目にも注意を払うことが可能になります。
管理会計では、原価計算の精度をあげるために活動基準原価計算（Activity Based Costing）という手法が活用されています。進捗管理会議の開催など間接コストをWBSの作業項目にきっちり入れ計測することで計算が可能となります。ただし、かなり煩雑な作業となるので自動化できる工夫が必要です。
リスクと対応をスケジュールに盛り込んでおく
リスクと対応策をスケジュールに盛り込んでおく
例えば、前提としていた要求定義が法律改正によって変わってしまった。委託していた協力会社が倒産してしまった。という極端なリスクから、来月からアサインを予定していたメンバーが前のプロジェクトの遅れから1ケ月遅れのアサインになってしまうようなリスクです。
プロジェクト期間中に発生しそうなリスクを想定し、書きだしておきます。法律改正のような外部環境もあれば、受注側、委託先などステークホルダーによるリスク、また社内で発生するリスクがあります。次にリスクがどれぐらいの可能性で起こりそうか、起きた場合にプロジェクトにどれぐらいの影響を与えるか評価しておきます。
影響が高く、発生可能性が高いリスクについては、なんとか下げられないか検討しますがゼロにすることは不可能です。リスクが発生した場合にどう対応するかスケジュールに盛り込んでおきます。
例えば、システムテストが始まり終了予定の1週間前になってもバグが出続け、品質が安定しない場合、現象としてはバグが出続け、バグの累積をプロットしたバグ曲線がなかなか平坦になりません。バグ曲線が収束しそうにない場合、役員へ事実報告し運用開始の延期要請という緊急時対応をスケジュールにあらかじめ盛り込んでおきます。
こういった仕組みをスケジュールに盛り込んでおくことで、報告が役員に届き、適切な判断ができるようになります。単なるスケージュールだけでは対応が後手後手に回ってしまい、適切なタイミングで適切な報告が行われません。結果として、そのまま運用開始してしまい、システム停止で役員が頭を下げるシーンがテレビや新聞で報道されることになってしまいます。
■参考記事
プロジェクト・マネジメントの極意
システム開発の注意点
徳川家康 石橋をわたるシステム作り
