![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
プロジェクトが混乱しているときにいったん止めてでも立て直させる場合は「ストップ」、本当に打ち切る場合は「ターミネート」を使う。
プログラムのフェーズゲートは通常、2階層になる。一つは経営やポートフォリオの立場からプログラムをモニタリング、コントロールする階層、もう一つはプログラムの立場からプロジェクトをモニタリング、コントロールする階層だ。前者は期や年度の切り替わり、あるいは予算時期や重要なプロジェクトの開始/終了時期など、プログラムの節目に開催する。満たしているかどうかの意思決定は「マネジメントデシジョンボード」や「ガバナンスボード」と呼ばれる委員会で行うケースが多い。
一方の後者のフェーズゲートは、プログラム内のプロジェクトの計画完了や設計完了などの時期に開催する。こちらの意思決定者は、プログラムマネジャーだ。問題があればマネジメントデシジョンボードなどにエスカレーションする。どちらのフェーズゲートでも事前に権限や責任など、意思決定の仕組みを明確にしておこう。
5 プラスのリスクに対処する リスク要因を洗い出し、影響度などを分析して優先順位を付け、リスクへの対応策を検討する。このリスクマネジメントのやり方自体は、プロジェクトマネジメントと変わりはない。変わるのは、ベネフィットに影響を与えるリスク要因が対象になる点だ。経済的な指標だけでなく、市場の拡大や競争力強化、ビジネスプロセスの改善など、ビジネスの役に立つかどうかがリスク対象となる。
具体的には、競合相手の出方や景気変動、研究開発がうまくいかないといったことがリスク要因となる。特にイノベーションパターンの場合は、プログラム外のリスクが増え、自分たちでは全くコントロールできないケースがある。それでもさまざまなリスクを洗い出し、対応策を考えるのがプログラムのリスクマネジメントだ。
半面、悪いことばかりがリスクではない。リスクとは振れ幅のこと。マイナスのリスクは押さえる一方、プラスのリスクを活かしていくのが基本だ。
もちろん、プラスのリスクを最初から期待して計画を作ることはない。だが、振れ幅が大きいイノベーションパターンでは、追い風が吹くケースなどプラスのリスクのシナリオを描いて備えておくことも求められる。
6 残資金に目を向ける プロジェクトマネジメントの場合、ユーザー側であれば予算金額、ベンダー側であれば受注金額をベースラインとしてコストマネジメントすればよかった。しかしプログラムの場合、プログラムを継続するための予算化や資金調達を自らやる必要がある。それがフィナンシャルマネジメントだ。
ITプロジェクトの場合、ファンドを募るようなケースはまれで、利用部門が予算化するケースが多い。しかし大規模なプログラムでは潤沢な資金が不可欠だ。プログラムマネジャーは、各プロジェクトの見積もりと資金繰りに目を向けて、資金がショートしないように残資金の管理をしっかりマネジメントしなければならない。当然、プログラムマネジャーにはフィナンスに関する知識やスキルが必要だ。
