プログラム/プロジェクトマネジメント
●’正しく’を実現する3つのマネジメント手法
事業経営に必要なリーダーシップ(目標設定とそこに向かう戦略)とマネジメント(戦略の実行)の組織能力のうち、マネジメントに関して、ポートフォリオ、プログラム、プロジェクト、の3つの手法が標準として提起されています。
3つのマネジメント手法の違いは;
ポートフォリオ~戦略目標達成へ、正しい施策の組み合わせ
プログラム~施策実行のうち、戦略目標の要素である正しい’ベネフィット’(実益)の創出
プロジェクト~施策実行のうち、ベネフィット創出へ基礎となる成果物の正しい作りこみ方
●ベネフィットって何だろう? ~ プロジェクト成果から生み出す実益のことです
成果物とベネフィットは何がちがうのか? ベネフィットを創出するマネジメント、’プログラムマネジメント’ の理解へ、以下のリンクにある資料をお勧めします。社団法人行政情報システム研究所発行のものです。
この資料を要約し、手っ取り早くプログラムマネジメントを理解してみましょう。
当団体は、ベネフィットを実益と訳しています。この実益とプロジェクト成果、および戦略目標の関係を25ページにある図を以下に再掲載し、説明します。
左側のプロジェクトによる成果物から、右側の意図した戦略目標達成へ、期待されるベネフィットの連鎖が表記されています。
この事例では、運動公園や選手村の設営、駅の改築などのプロジェクト成果物は、その投資目的が地域経済の活性化であり、そこへ至る数々の実益が想定されていたのです。
これら実益のことを’ベネフィット’と称しています。そして、このベネフィット創出の連鎖をマネジメントする手法が、プログラムマネジメントなのです。
●3つの’正しく’のおさらい
戦略目標達成へ、実益の想定が正しいか?、実益を得るための成果物を正しく作ることができるか?
これらを、投資スポンサーから、末端の実務者、受益者まで、膨大な利害関係者を巻き込み進める手段が、ポートフォリオ、プログラム、プロジェクト・マネジメントなのです。
● 標準化の動向
ポートフォリオマネジメント同様、各団体にて標準化もしくはモデルが定義されています。
米国: 連邦政府の調達標準としてPMIAA法制化
英国: 商務局(OGC)によるPRINCE2、P3RM
ISO: ISO21500。TC258にてPPP標準化の作業中
国内においても、米国PMIのPMI標準の普及だけでなく、プロジェクトマネジメント協会が標準を定めています。
これら標準の動向としては、前掲のとおり、プロジェクトマネジメント手法の啓蒙から、ベネフィット(実益)創出のマネジメント、つまりプログラムマネジメントへ、延いてはポートフォリオマネジメントへと、戦略目標達成へ正しい施策を正しく行う(Doing right things do right)を標榜しています。
● なぜ標準化が必要?
グローバルなアライアンスが当たり前になり、様々なカルチャーの人間が共通理解で協業を行うことが必要になり、その場合、皆が同じ言葉を同じ意味で使う必要があります。これが基本的な標準化の意図でしょう。
一方で各国政府は推進するのは、投資を効率的に使う、つまり無駄な公共投資を避けたい背景があります。
下記は、米国PMIのアナウンスレターの抜粋です。米国政府の調達にプログラムマネジメントが法制化されたという内容です。
背景分析として、過去の投資効率が言及されています。
on 14 December, President Barack Obama signed The Program Management Improvement and Accountability Act of 2015 (PMIAA) into law.
This new law will improve United States federal government project and program management by:
• Creating a formal job series and career path for program and project managers
• Developing a standards-based model for program and project management
• Designating a senior executive responsible for project and program management policy and strategy
• Leveraging an interagency council on program management to share best practices
According to PMI research, only 64 percent of government strategic initiatives ever meet their goals and business intent — and government entities waste $101 million for every $1 billion spent on project and programs. The reforms outlined in the PMIAA align with PMI member input that indicates organizations who invest in program management talent and standards improve outcomes, accountability and efficiency. The passage of PMIAA into law illustrates an acknowledgement of the value of project and program management by the United States government, and therefore lays an important groundwork as PMI continues to advocate for the profession in governments around the world
● 働き方改革の本質
以下の文書は、オーストラリア政府の調達ルールとして法制化されている、Benefit Realization Management標準です。企業は調達に応札する際に、成果物への作業計画だけでなく、そこから実益をどのように得るか、を提案することが義務付けられています。また、実益創出へのマネジメントスキームも含まれていなければなりません。
一般企業もこれを見習い、投資も同様なスキームで行われると、目標と責任が明確な元に仕事ができるはずです。働き方改革の本質はここである気がしてなりません。
個人に目を向ければ、動機付けこそが改革の本質で、そこに向けてはドラッガーさんも、経営の権限委譲こそが重要である趣旨のことを発表されています。
権限委譲された実行責任と、それをベネフィット軸でガバナンスする経営者、の構図こそがモダンな経営体でしょう。そこに向けてこのBRMは手本とすべき経営スキームなのです。
潜在的キャズム
● マネジメントセオリーは成熟域に。プロジェクト設計の品質が成否を左右
セオリーは、その歴史において、充分検証・改善され、成熟期にあると言えるでしょう。
セオリーと実務の間のキャズム、というよりは、その前提としている条件が整わない環境課題を取り上げます。
請負型では、契約時のQCDが、契約後に発注方から変化してしまうことです。日本の商習慣においては、請負側の立場が弱く、契約の変更を求めても受け入れられないことで、プロジェクトが苦境に陥るようなケースです。
商品開発型の場合は、技術的に未成熟な要素技術を組み入れた開発案件です。本来は、要素技術開発として独立させて管理すべきところを、商品開発の中で技術開発を同時並行させ、それによりQCDが達成できなくなるケースです。
(つづく)
キャズムを繋ぐ知恵
● ミッション実現への統合マネジメントはプログラムで
商品開発系においても、事業ミッション達成に向けては、複数プロジェクトの統合管理、後継プロジェクトの統合管理が必要です。
図は、事業ミッション達成を起点にした統合マネジメントの基本フレームワークです。この目標達成へのスキームとしてPDCAを実施していくことが、プログラムマネジメントに他なりません。
マネジメント構造化の視点は4点です;
- ミッション
- 実現へ取組み構造化(アーキテクチャ)
- オファリング価値
- コミュニティと資源管理
マネジメント対象は4点です;
- 構造の達成度
- オファリング価値の評価
- 構造およびオファリング価値のバリアンス
- ミッションプロファイル
(つづく)
● プロジェクトの前提条件設定とリスク管理
条件が整わない上記事例において、プロジェクトマネジメントセオリー上で解決するとすれば、リスクの見極めと管理に落とし込むことでしょう。プロジェクト実行の条件とする理想的な環境を想定し、そこからの齟齬をリスクとして明示し、共有することです。
請負型:
QCD変更自体は、プロジェクトマネジメントの一プロセスとして確立されています。
請負型においては、変更管理プロセスを合意し、判断の場、ボードまで明確にしておくことで、一方的な変更要求であっても、そのプロセスに入れ込み、プロジェクト課題としてだけでなく、発注側と請負側間の二社間の交渉事として取り扱う余地が生まれます。
商品型:
未完成な技術を組み入れた場合、その達成に向かうリスクは計り知れません。商品開発プロジェクトでは、目標QCDを仮定し、ビジネスケースまで約束するわけですから、プロジェクトとしては如何にその計り知れないリスクを明確にして合意するかが、唯一の手立てでしょう。
プロジェクト発足あたりのフェーズになると、事業計画や開発プロセスに立ち戻ることは実務上困難な場合も多いと思います。 その空気感は、経験者には思い当たることがあると思います。
いずれにせよ、プロジェクトの前提条件が変わることを、プロジェクトリスクとして取り込み設計することは、QCDを見直す変更管理の範疇であることは間違いありません。要は常にプロジェクトをできるだけ健全な環境で実施するためであり、これは合意形成のプロセスの出来不出来に左右されるでしょう。
事例を探し紹介していきたいと思います。軋轢無くボトムアップで対処できる方法ですね。
(つづく)
● 事例 Agile & Lean Methodへの転換
参照記事:PM Network, April 2011
変革に関する記事を紹介します。
開発手法は、Waterfall、Spiral、そしてAgile、へとそのバリエーションが拡がっています。以下は、ものづくり大企業の変革と某IT系ベンダーの変革(Agile化)の対比考察です。
GMとトヨタの合弁会社のNewUnitedMotorMfgInc.(NUMMI)は、お互いのKnowHowを共有し、品質向上させることを目的に80年代に発足しました。目標達成は達成できたのですが、30年の時間を要しました。
一方のITベンダーは、その転換を僅かな期間で達成しました。異文化大製造業合弁とIT系小企業の差は考慮に入れるべきでしょうが、その考察された対比軸は以下です。
Accuracy<>Productivity
Empowerment<>Heroism
各、後記を変革への阻害要因として挙げています。つまり;
生産性のために品質を犠牲にする
ヒーローを賞賛する (日本で言うところの、スーパーマンや火消しの達人を賞賛する、の意味合いでしょう)
Agile化は現場へ、各構成員へ、の権限委譲により、各人がコミットし、相互に信頼されることで、小さな課題解決の積み重ねを図ります。ヒーローが最終局面に立ち回り解決する、といったよく見かける帳尻合わせ、とは対極にあたり、これらの阻害要因の打開策です。
同様な事例を紹介します。
IBMでは、90年代の大規模な変革の中に、品質管理部門を廃止しています。それまで各事業部門から独立した品質部門が全製品を同一基準で検証していたプロセスを撤廃し、各プロジェクトへ品質管理権限を委譲しました。これにより、各プロジェクトはそのビジネス意図に見合った品質基準を設定し、チーム自らがその達成に注力するようになりました。
これもAgile化の事例と言えるでしょう。