PMP：共通 - OPM - プログラム・マネジメント のバックアップ(No.4)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• PMP：共通 - OPM - プログラム・マネジメント へ行く。
  • 1 (2019-05-10 (金) 14:43:42)
  • 2 (2019-05-10 (金) 16:39:20)
  • 3 (2019-05-20 (月) 09:59:40)
  • 4 (2019-07-24 (水) 15:20:14)
  • 5 (2019-07-26 (金) 09:56:00)
  • 6 (2019-07-31 (水) 11:15:37)
  • 7 (2019-08-10 (土) 16:00:53)
  • 8 (2020-02-04 (火) 19:44:11)
  • 9 (2020-02-06 (木) 10:50:01)
  • 10 (2020-02-06 (木) 12:33:31)
  • 11 (2020-04-03 (金) 14:15:36)
  • 12 (2020-10-22 (木) 10:27:17)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

• 組織的プロジェクト・マネジメント（OPM） 中のプログラム・マネジメント

• ベネフィットを実現するために、

• サブプログラム、
• プロジェクト

の相互依存関係をコントロールする（調和させる）。

• ベネフィットへのコミットと言う意味では、
  スコープやQCDにコミットするプロジェクト・マネジメントより、
  プログラム・マネジメントの重要性が高まって来ている。

プログラム †

プログラムとは、

• 組織の戦略的変更を達成する手段
• 関連プロジェクト、サブプログラム、サブプロジェクト、作業グループから成る。
• 類似のプログラム・マネジメント技法を使って調和がとれるようにマネジメントされる。

マネジメント †

プログラムのマネジメントとは、

目的 †

• ベネフィット、デザイアード・アウトカム、戦略目標の達成
• マネージング・コンプレックス・プロジェクト

領域 †

• 対象
  （プログラムの）相互依存関係
  • （サブプログラム、プロジェクトの）集合体の関係
  • ベネフィット達成のために、プロジェクトの貢献を統合
    • スケジュール、リソースの全体最適化
    • リスクなどマネジメント・フレームワークを使用してマネジメント
    • 合理化・監視・コントロール、エスカレーションされた問題の管理と解決

• 非対称
  • プロジェクト単体のマネジメント
  • アウトプット、プロフィット

環境 †

• 合併と買収
• 政府と法令
• 管理されたオペレーション
• テクノロジー
• プロダクト開発

複雑性 †

• 地理
  • グローバル・チーム
  • バーチャル・チーム

• 組織
  • マトリックス組織

• 環境変化
  • 法的規制
  • 規模・スコープ
  • ステークホルダー
  • テクノロジー
  • 組織戦略
  • 組織変革
  • その板

知識エリア †

プログラム *** マネジメント

• 統合
• 範囲
• 時間
• 原価
• 品質
• 資源
• 調達
• リスク
• コミュニケーション
• ステークホルダー

• 追加
  • ファイナンス
  • ガバナンス

コンピテンシー †

例 †

• 相互依存関係の規定と制約条件の調整によるプログラム間の問題の解決。

• 生活・仕事・ショッピングが揃った職住一体型団地のプログラム

• プログラム
  • 各エリアの設計と設置
  • マーケティング
  • 施工管理

• 体制
  • ヘッド PM
  • サブ PM

キーワード †

PM → PgM †

• プロジェクト・マネージャー（PM）
• プログラム・マネージャー（PgM）

プロフィット → ベネフィット †

• プロフィット（利益）ではなくベネフィット（恩恵・便益）
• PgMはPMが要求されなかったベネフィットに対してコミット

アウトプット → アウトカム †

望ましい成果（デザイアード・アウトカム）

• アウトプット（成果物）ではなくアウトカム（結果、成果）
• インカム（収入）ではなくアウトカム（結果、成果）

戦略目標と行動変容 †

戦略目標の達成は、行動変容によって発生するベネフィットによる。

AS-IS → 行動変容、ベネフィット → TO-BE（戦略目標の達成）

考慮点 †

オペレーションの維持 †

• 作業関係
  定常業務との関連

• 責任

• 組織
  • 戦略の整合性
  • ベネフィット評価
  • 財務分析
  • 成果の状況

• プログラム
  • 依存関係
  • 各知識エリア
  • ファイナンス
  • ガバナンス
    メトリクス・測定値

• プロジェクト

• 引継
  定常業務やプロダクト・サポートへの引継

ライフサイクル †

詳細 †

プログラムの3パターン †

分割パターン †

大きなプロジェクトを細かく切った状態にして
スコープを分割すれば、大規模プロジェクトの成功率を高められる。

段階的パターン †

大きなプロジェクトを細かく切った状態にして
時間軸に沿って順次プロジェクトを立ち上げ、段階的に仕上げていく。

イノベーション・パターン †

コードネームを付けて「○○計画」と表現する場合など、新事業や新製品・サービスを創出するケース。

• 新商品・サービスの開発では、

• 商品企画、研究開発、マーケティング、商品開発、プロモーションなど、
  異なる部署間で有機的なつながりを持つプロジェクトが立ち上がる。

• しかも、することがある。
  • あるプロジェクトの結果が他のプロジェクトに影響したり、
  • 世の中の変化に対応して進む方向を変えたり、

• この場合、経営とプロジェクトをつなぐ役割として、プログラムマネジャーを置く。
  関連するプロジェクトへのガバナンス、コントロール、打ち切りの判断が容易になる。

• フェーズゲート
  あらかじめフェーズゲートを設定しておけば、適切に意思決定できるようになる。
  • 研究開発プロジェクトの打ち切りや、競合相手など外部環境変化に伴い大きな方向転換を迫られるかもしれない。
  • プロジェクト側は当然、続けたいと思っているので、実際に打ち切るとなると強い抵抗がある。

• リスク・マネジメント
  イノベーション・パターンのプログラムでは外部リスクが増え振れ、且つ幅も大きい。
  • 自分たちでは全くコントロールできないケースがある。
  • それでもさまざまなリスクを洗い出し、対応策を考える。
  • また、プラスのリスク（好機）のシナリオを描いて備えておくことも求められる。

マネジャー、チームメンバーの役割 †

プログラム・マネジャー、プログラム・チームメンバーは何をするのか。

• サポートはPMO
• 成果を出すのはプロジェクト

分割パターン †

• チームメンバーはプログラムの初期段階から参加。
• プログラムマネジャーと一緒に計画を立てる。
• プロジェクトが発足すると、プロジェクトの中心メンバーとして加わる。
• 発注する場合は、ユーザー側ならカウンターパーソンのような役割に就く。

段階的パターン †

• チームメンバーは技術やノウハウを引き継いでいく人たち
• 中核メンバーは、計画段階からアサインする必要がある。

イノベーション・パターン †

• チームメンバーはコアとなる技術を持つ人で、いわゆる「尖った人」となるケースが多い。
• プログラム・マネジャーは、こうしたチームメンバーをどのように活用するか考える。

7大テーマ †

各プロジェクトをまとめるには、以下が必要

• 権限やコミュニケーション力、
• そして何にも増して意思決定力

明確なビジョンを持つ †

プログラム成功の鍵となる。

• プログラムは長期にわたるため、プログラムを取り巻く市場環境が大きく変わりやすい。
• それに伴って計画も大きく変動するが、この際、明確なビジョンが拠り所になる。

ベネフィットを追求する †

• プロジェクト・マネジメントは「プロフィット」を追求する。
  • QCD（品質・コスト・納期）
  • CS（顧客満足度）

• プログラム・マネジメントは「ベネフィット」を追求しなければならない。
  • モノを作る過程だけでなく、プロジェクトやプログラムを通じて
    作り出されたモノがビジネスの役に立つかどうかが評価の対象となる。
  • 市場の拡大や競争力強化、ビジネスプロセスの改善、運用改善などを達成しなければならない。
  • 直接金銭的な価値に結びつくものばかりではないのでベネフィットと呼ばれる。

多くのステークホルダーを巻き込む †

ステークホルダーマネジメントを行う。

• プロジェクトに比べてステークホルダーの数と種類が圧倒的に増える
• ステークホルダーごとにプログラムへの期待やニーズ、影響力などがそれぞれ異なる。

ガバナンスを利かせる †

「フェーズゲート」でプログラム傘下のプロジェクトにガバナンスを利かせる。

• 目的はビジョンやミッションからの逸脱防止やリスク軽減、経営的な利益最大化である。
  • プログラムやプロジェクトをいくつかのフェーズに分け、次フェーズに移るときにゲートを設ける。
  • 各ゲートでは、プログラムの立場からプロジェクトの「ゴー」「ノーゴー」の判定を下す。
    • 「ゴー」
    • 「ノーゴー」
      「指摘された懸念事項や問題を解決してから進みなさい」という意味。

• プロジェクトの打ち切り。
  • 「ストップ」
    混乱しているときに止めて立て直させる場合
  • 「ターミネート」
    本当に打ち切る場合

• プログラムのフェーズゲートは通常、2階層になる。

• 経営やポートフォリオの立場からプログラムをモニタリング、コントロールする階層
  • 期や年度の切り替わり、あるいは予算時期や重要なプロジェクトの開始/終了時期など、プログラムの節目に開催。
  • 満たしているかどうかの意思決定は「マネジメント・デシジョンボード」や「ガバナンスボード」と呼ばれる委員会で行う。

• プログラムの立場からプロジェクトをモニタリング、コントロールする階層
  • プログラム内のプロジェクトの計画完了や設計完了などの時期に開催する。
  • こちらのは、プログラムマネジャーが意思決定する。問題があればマネジメント・デシジョンボードなどにエスカレーションする。

プラスのリスクに対処する †

• リスクとは振れ幅のこと。
  • マイナスのリスクは押さえる一方、
  • プラスのリスクを活かしていく

のが基本。

• リスク・マネジメントのやり方自体は、プロジェクト・マネジメントと変わりはない。
  • リスク要因を洗い出し
  • 影響度などを分析して優先順位を付け
  • リスクへの対応策を検討する。

• 変わるのは、ベネフィットに影響を与えるリスク要因が対象になる点。
  • 経済的な指標だけでなく
  • ビジネスの役に立つかどうかがマネジメント対象となる。
    • 市場の拡大や競争力強化、
    • ビジネスプロセスの改善

残資金に目を向ける †

• コスト・マネジメント
  プロジェクトマネジメントの場合、
  • ユーザー側であれば予算金額を
  • ベンダー側であれば受注金額を

ベースラインとしてコスト・マネジメントすればよかった。

• フィナンシャル・マネジメント
  プログラムの場合、フィナンシャル・マネジメントが必要になる。

• プログラムを継続するための予算化や資金調達を自らやる必要がある。
• ITプロジェクトの場合、ファンドを募るようなケースは稀で、利用部門が予算化。

• 大規模なプログラムでは潤沢な資金が不可欠。
  • 各プロジェクトの見積もりと資金繰りに目を向けて、
    資金がショートしないように残資金を管理する。
  • フィナンス（資金調達）に関する知識やスキルが必要。

支援体制（PMO）を作る †

プログラムマネジメントオフィス（PMO）の役割

• 一つめは、
  各プロジェクトとのコミュニケーション

• 二つめは、
  影響力を持つステークホルダーへのレポート作成。

• 三つめは、
  フェーズゲートの運営

• プログラムは長期にわたるケースが多いので、フェーズゲートを形骸化させない仕組みが必要。
• これをプログラムマネジメントオフィスが担い、経営幹部など出席者のアサインや会議室/日程確保などを行う。

• その他の役割 各プロジェクトの
  • 参加メンバーの育成
  • ITアーキテクチャ検討
  • ITインフラ整備
  • 各種手法・ツールの標準化・推進
  • ナレッジや教訓の吸い上げ、横展開

参考 †

２版が具体的。３版、４版と版を重ねる毎に、抽象化している。

• プログラムマネジメント標準 第4版 (日本語版
  https://www.pmi-japan.org/bookstore/pm_std/pgm4thjpn.php

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.046 sec.