プログラム

プロジェクトvsプログラム

プロジェクトは、繰り返し行われる操作ではないという意味でユニークであり、始まりと終わりがあるという意味で有限であると定義されます。

一方プログラムは、1つのプロジェクトだけでは得られない利益を実現するために、関連するプロジェクトを連携して管理するグループと定義されます。

例えば、技術的なネットワークメンテナンスプログラムには、ソフトウェアアップグレード、データ移行、ハードウェアアップグレード、ライセンス、調達、品質保証に関連するそれぞれ個別のプロジェクトが含まれることが考えられます。これらのプロジェクトはそれぞれ特定の目標を達成するものであり、これらを合わせてメンテナンスプログラム全体を構成します。プロジェクトはプログラムなしでも存在できますが、プログラムは常に関連するプロジェクトで構成されます。

プロジェクトとプログラムの主な違いは、次の通りです。

  • 構造:プロジェクトは、プロジェクトの範囲と目的を正確に記したプロジェクト憲章によって正確に定義されます。一方プログラムは、不確実性が高い傾向があります。また、チームも大きくなります。プログラムチームは複数のプロジェクトの作業を監督・調整するため、コアチームのメンバーは数人かもしれませんが、プロジェクトマネージャーやプロジェクトチームメンバーを含むグループはより広範囲になります。

  • 労力:これこそが、プロジェクトとプログラムの最も大きな違いです。プロジェクトは単純な労力です。プロジェクトチームは共通の目標に向かって努力します。一方プログラムは、プロジェクトの集合体です。すべてのプロジェクトが集まって一つのまとまりを形成します。プロジェクト同士が補完し合い、プログラムの全体的な目標達成を支援します。プロジェクト間には重複や依存関係もありうるので、プログラムマネージャーはそれらを見極め、関係するプロジェクトマネージャーと協力して、プログラム全体が円滑に進むようにしなければなりません。

  • 期間:プロジェクトによっては数年続くものもありますが、ほとんどのプロジェクトは短期間で終了します。一方、プログラムは間違いなく長期間となります。その範囲は広く、目的を達成するには時間がかかります。プログラムは、フェーズに分割される傾向があります。プロジェクトも同じように分割されることがありますが、多くの場合、複数のフェーズに分けて完了できるほど長くは続きません。

  • 利益:プロジェクトチームは、ある特定の成果(最終的に実現されるもの)の達成に向けて活動します。この成果は、ソフトウェアパッケージや小売店の新店舗など、一連の成果物である可能性があります。プロジェクトの利益は、最終的に何が達成されたかという点で目に見えるものになる傾向があります。プログラムチームは、成果物を提供するために働きます。この成果は目に見えるものである場合もありますが、そうでない場合も多くあります。プログラムの利益は、すべての異なるプロジェクトの利益の合計です。実際、政策や文化の変化、組織の働き方のシフトをもたらすことも可能です。

  • 財務:プログラムは、組織の財務カレンダーと連動します。プログラムマネージャーは、他のビジネス部門と同様、四半期ごとの業績に左右されることもあります。プログラムは財務管理の範囲が広く、プロジェクトは通常、単純な予算です。プロジェクトの財務管理は、支出を予算の範囲内に抑えることに重点を置いています。プログラムマネージャーは、組織の財務にとって重要な収入とコストを担当することがあります。予算計画、管理、統制は、プログラムという文脈ではかなり複雑になります。

プログラムマネジメント

プログラムマネジメントとは、一連の事業目的を達成するため、一定の期間に渡り、相互依存関係にある複数のプロジェクト連携して管理することです。

  • 複数のプロジェクトの連携管理とは、プログラムのコアチームによってプログラムレベルで実行される共通のライフサイクルを枠組みとして、各プロジェクトチームの作業を同期させることです。

  • 相互依存プロジェクトとは、他のプロジェクトのアウトプットに相互の依存関係を持つプロジェクトです。プログラムマネジメントは、協調して管理される複数のプロジェクト間の依存関係を保証します。

  • 一定の期間とは、その性質上、一時的なプログラムに特定の始めと終わりを定義するものです。プログラムは、明確に定義された事業目的を持って開始し、その目的を達成した時に終了する期間が制限された一度限りの事業です。

  • 決められた事業目的を達成することは、プログラムで何よりも優先される目的であり、プログラムマネージャの根本的な責任です。事業目的としては、販売促進とマージンアップによるマーケットシェアの拡大と利益の増加、品質とカスタマーサポートの向上によるブランド力の強化などが考えられます。

トップダウンとボトムアップアプローチ

プログラムプランニングでは、ほとんどのプログラムマネジャーは、プログラムを校正する個々のプロジェクトのプランニングを特定し、実行するボトムアップアプローチを使います。

まず、各プロジェクトマネージャーが、プロジェクトの成果物を提供するために必要なリソースを見積もり、配分する計画を構築します。このステップでは、マネージャーは単体のプロジェクトを計画するときと同じ技法と実践を使います。

次にプロジェクトマネージャーは、プログラムのプロジェクト間のつながりと依存関係を識別し、各プロジェクトが他のプロジェクトと統合できるように、プロジェクト計画を練り直し、作り直します。

この統合作業では、各プロジェクトで計画されている製品、必要なリソースの量や種類を調整する必要がある場合が多く、当然ながらスケジュールも変更されることになります。プログラムマネージャーにとっては、プロジェクト間の依存関係を継続的に管理し、調整する能力が、プログラムの成功の重要な決め手となります。またこれが、プロジェクトプランニングとプログラムプランニングの要求事項の大きな違いでもあります。

image5.png

上記の例では、

  • プロジェクトAはソースオブジェクトです。

  • プログラムXのプロジェクトAはターゲットオブジェクトです。

一方、定期的に会合を開くプログラム運営委員会が、サブプロジェクトの目標値や納期を決めることもあります。

トップダウンアプローチでは、これらの目標が対応するプロジェクトに割り当てられます。プロジェクトマネージャーはそれを実行しなければなりません。

image3.png

上記の例では、

  • プログラムXのMst 1Xはソースオブジェクトです。

  • プロジェクト!のMst 1Xはターゲットオブジェクトです。

プログラムを管理するためには、トップダウンとボトムアップの一貫したコミュニケーションを確立し、目標や現在のマイルストンを伝える必要があります。このコミュニケーションにより、プログラムマネージャーはプロジェクトのパフォーマンスをよりよくコントロールすることができるようになります。

Sciformaでは、依存機能を使ってこのコミュニケーションを行います。