PMstyle 2024年4月~6月Zoom公開セミナー(★:開催決定)

カテゴリ

Powered by Six Apart

« 2006年7月 | メイン | 2006年9月 »

2006年8月

2006年8月29日 (火)

プログラムマネジメントはまだ早い?

「うちではプログラムマネジメントはまだ早い。もう少し、プロジェクトマネジメントをしっかりやって足元を固めてからの話だ」

プログラムマネジメントセミナーの告知を始めて何人からかこの指摘をされた。

いわんとすることはもちろん、よく分かる。一方で、早いとか、遅いという問題かなとも思う。遅い、早いを言い出すと、おそらく「鶏が先か、卵が先か」という議論になる。

大切なことはこの2つは「似て非なるもの」であり、そして、「補完しあうもの」だということをしっかりと理解することだ。異なるものだという認識をすることだ。プログラムマネジメントやマルチプロジェクトマネジメントは一種の組織マネジメントであり、一種の組織マネジメントである。これに対して、プロジェクトマネジメントはオペレーションのマネジメントである。

これは失敗を考えてみるとよく分かる。商品は書くことができないが、技術コンサルティングをやっていた頃に、電子機器メーカX社で商品Aの開発プロジェクトの(開発マネジメント)コンサルティングの仕事をしたことがある。この商品はある事業(商品ラインナップ)の戦略商品であり、この商品で競合メーカY社とのカテゴリシェア(5%差)を逆転することを狙っていた。当然、組織としてもテコ入れをして進めていった。

ところが残念なことに設計の見通しが甘く、3ヶ月発売が遅れ、結果として競合商品に2ヶ月の遅れを取ると予想された。プロジェクトとしては完全に失敗である。

遅れが判明したころから、商品Aの投入後に販促を兼ねて投入する予定だったソリューションサービスの繰上げ開始を決定し、売り上げを維持するために旧商品を使ってソリューションビジネスを展開することにした。これが功を奏した。競合製品の登場から2ヶ月の間、旧商品はシェアを維持し続けた。結局、Y社の商品より4ヶ月遅れて商品Aは市場に投入され、時間をかけて練られた分、ユーザにとって魅力的な商品に仕上がり、1%であったがカテゴリシェアを逆転した。これはプログラムマネジメントとしては大成功である。

この問題は、プロジェクトマネジメントをきっちりとやれば済むと言い切れない部分がある。ここでプロジェクトマネジメントをきちんとやると、プログラムの目的を忘れて、プロジェクトを失敗させないために「スコープ削減」に出ることが多い。ここでプロジェクトが踏ん張り、納期を遅らせてもプログラム目標を達成できると信じる仕様を守りきれるかどうかが企業の製品開発力であり、そのためには、プログラムマネジメントが不可欠である。

逆にいえば、プログラムマネジメントができて初めて、プロジェクトマネジメントが上のような適切な判断ができるようになる。この関係をよく頭に入れて、プロジェクトマネジメントの強化の一方で、必ず、プログラムマネジメントの強化を行う必要がある。

プログラムマネジメントの導入に速すぎることはない。上の例のように、プログラムマネジメントでプロジェクトマネジメントスキルの不足を補うこともあるのだ。

プログラムマネジメントのスキルが最も必要なのは、プロジェクトスポンサーである。プロジェクトスポンサーの仕事はプログラムマネジャーの仕事だといってもよいくらいだ。もちろん、実質的にプロジェクトスポンサーをかねているような「プレイングプログラムマネジャー」のようなプロジェクトマネジャーにとっても重要なスキルだ。

〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
 ◆プログラムマネジメント
   ~複数のプロジェクトを同時に成功させる方法とそのポイント<7PDU>
  日時:2006年09月21日 10:00-17:00
  場所:全国農業共済会館3F テクノ研修センター(東京・千代田区)
  講師:好川哲人(プロジェクトマネジメントオフィス)
  詳細・お申込 http://www.pmstyle.biz/smn/mpm.htm
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
【カリキュラム】
1.いかに複数のプロジェクトをマネジメントするか
2.マルチプロジェクトマネジメントに関するPMIの標準
3.プログラムマネジメントの概要
4.プログラムにおけるプロジェクト間のコンフリクトの解消
5.プログラムのプロジェクトのスケジュール管理とリソース管理
6.プログラムのリスク管理
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

2006年8月 7日 (月)

続・コミュニケーションをマネジメントしよう

前回は、コミュニケーションとコミュニケーションマネジメントとは違うということをお話しました。では、今回はコミュニケーションマネジメントとは何かについてお話をしたいと思います。

Comm2 ◆コミュニケーションマネジメントとは何か

コミュニケーションの動機には、道具的コミュニケーションと、充足的コミュニケーションがあるといわれています。前者は進捗報告のようなもので、主に情報の共有を目的とし、その手段をしてコミュニケーションを行うものです。これに対して、後者は困ったときに相談にのる、励ます、というように、コミュニケーションそのものが目的というコミュニケーションです。

これらのコミュニケーションが行われるためには、「動機」が必要になります。充足的なコミュニケーションの動機は「相談してみよう」とか、「励ましてやろう」といった心理的(内発的)なものが多くなります。問題は、道具的コミュニケーションの動機です。道具的コミュニケーションの動機づけをすることはマネジメントの責任です。例えば、進捗報告であれば、進捗報告を行う「ルール」を作っておくことがコミュニケーションをする(外発的)動機付けになります。このように道具的コミュニケーションは外発的な動機によって行われることが多く、外発的な動機付けはマネジメントの責任だといえます。

前回、お話した「問題があれば報告してね」というやり方の問題点は、「問題」とは何かを定義しない限り、ルール(動機)にならず、そこに問題点があるわけです。

その上で、その定義を意識しながら、如何に「問題」を識別するかは個人のスキルの問題になります。例えば、「問題とは20%の計画の差異である」ということが明確に決まっていたとしても、それをどの時点で認識するかは個人の感度の問題になります。この感度を上げるには一人ひとりが、スキルアップに取り組まねばなりません。

このように、メンバーのコミュニケーションスキルの育成も含めて、コミュニケーションをマネジメントする一連の仕事はコミュニケーションマネジメントと呼ばれ、PMBOKでもひとつの知識エリアになっています。

コミュニケーションマネジメントはプロジェクトマネジメントには不可欠なものであり、また、即効性という意味でのプロジェクトへのインパクトも極めて大きいものです。

by 好川哲人

◆関連セミナー

 プロジェクトを成功させるコミュニケーションマネジメント

  http://www.pmstyle.biz/smn/comm.htm

コミュニケーションをマネジメントしよう

◆コミュニケーションとコミュニケーションマネジメントを区別しよう

プロジェクトでコミュニケーションが大切なことはいまさら言うまでもないでしょう。プロジェクトマネージャーの仕事は問題管理とコミュニケーション管理だといってもよいくらいです。

ところが、多くの組織ではコミュニケーションはパーソナルなスキルの問題だと考えています。このため、コミュニケーションの改善は、人材育成/スキルアップとして行われていることが多いようです。このような捉え方は半分は的を得ていますが、半分は的外れです。

プロジェクトマネジメントのコンサルティングをしていますと、コミュニケーションがうまくいかないという問題意識を持っているケースの多くは、コミュニケーションの内容に関する問題であることに気づきます。

つまり、誰(Who)が、何(What)を、いつ(When)、どういう理由(Why)で、誰(Where)に報告すればよいか分からないため、プロジェクトメンバー間やステークホルダーとのコミュニケーションがスムーズに言っていないのです。

ところがこのような問題に対して、多くの組織は、個々人のコミュニケーションスキルの問題だと考えています。つまり、いかに(How)の問題だと考えているのです。ここが上で、的外れだと言っている部分です。

例えば、スケジュールに「問題」があれば報告してくださいといった場合、何が問題かということが明確になっていないと、コミュニケーションは成立しません。ところが、実際に「コミュニケーションが適切にできる」といった言い方をする場合、何が問題かという判断ができることまでを要求していることが多いのです。

Comm1_1 ■コミュニケーションマネジメントとは何か

これはマネジメントの怠慢だといえます。この場合、「問題」とは何かを定義することはマネジメントの仕事になります。

その上で、その定義を意識しながら、如何に「問題」を識別するかは個人のスキルの問題になります。例えば、人によって感度も違うでしょう。コミュニケーションのスキルアップというのはこの感度を上げることになります。

このように、メンバーのコミュニケーションスキルの育成も含めて、コミュニケーションをマネジメントする一連の仕事はコミュニケーションマネジメントと呼ばれ、PMBOKでもひとつの知識エリアになっています。

コミュニケーションマネジメントはプロジェクトマネジメントには不可欠なものであり、また、即効性という意味でのプロジェクトへのインパクトも極めて大きいものです。

by 好川哲人

◆関連セミナー

 プロジェクトを成功させるコミュニケーションマネジメント 

  http://www.pmstyle.biz/smn/comm.htm

レゴで学ぶPMBOKプロジェクトマネジメント

■ レゴで学ぶPMBOKプロジェクトマネジメント
   ~ プロジェクトマネジメントの実行スキルを身につける

PMBOKやプロジェクトマネジメントのトレーニングでは、ケーススタディが当たり前になってきました。弊社でももちろん、ケーススタディーを中心にした研修をたくさん行っています。

しかし、ケーススタディはあくまでも机上のものですので、実感がわかない、やってみないとわからないという受講者の声も多いのも事実です。例えば、本当の意味でリスクを学ぶことはケーススタディやシミュレーションでは難しいものがあります。

そこで、小さなプロジェクトで実際にプロジェクト計画を作り、その計画に従って進捗をコントロールしながらプロジェクトを進めるというセミナーを開発しました。

20060719a1  レゴブロック(LEGOマインドストーム)を使ってロボットを組み立てる、というプロジェクト計画を作り、コントロールし、実行するセミナーです。

LEGOマインドストームは、レゴ社とMIT ( マサチューセッツ工科大学 ) の研究から生まれたグラフィカルなプログラムで、レゴブロックで組み立てたロボットを動かすことのできるキットです。

簡単なプログラムでロボットを動かすことができますので、フローチャート(流れ図)を見たことがある方であれば、すぐ理解し、使うことができますので、プログラミング未経験者でもまったく問題はありません。

最初の課題では、LEGOマインドストームに慣れるために、簡単なロボット(車)を作ります。

そして、「前進2秒、左スピン2秒、ジグザグ2回、右スピン2秒」の動作をさせるプログラムを作成し、ロボットにLego0418_12ダウンロードし、動かしてみます。

この慣れるという作業においても、プロジェクトマネジメント計画書を策定し、その計画書にしたがって、実施します。

その際の制約条件は、次の通りです。

・プロジェクトマネージャーを決める
・プロジェクトマネージャーは作業を担当しない
・作業は分担して行う

プロジェクトマネジメント計画書とは、プロジェクトを進めるうえでのプロジェクトマネジメント全体の方針などを決めて文書化する計画書です。

そして、PMBOKの知識エリアである、統合、スコープ、タイム、コスト、品質、人的資源、コミュニケーション、リスク、調達別のマネジメント方針も決めて文書化します。

この後には、新しい課題をプロジェクト憲章として提示し、プロジェクト計画を策定し、プロジェクトを実行していくという流れになっています。

【セミナーの内容】

1.LEGOマインドストームに慣れる
 LEGOマインドストームの機能やモジュールになれるため、簡単な課題1を実施しま

2.課題2の分析とスコープ定義
 プロジェクト憲章と成果物記述書で課題が与えられ、その課題2を達成するためのスコープ定義を行います
3.計画を作る
 スケジュール、要員計画、品質計画、予算計画、リスク計画、コミュニケーション計画を作成します
4.開発作業の実施(1)
 課題の設計を行います
 開発チームとプロジェクトマネジメントチームにわかれ、進捗管理をフォーマットを使って行います
5.開発作業の実施(2)
 LEGOによる課題の組み立てを行います
 開発チームとプロジェクトマネジメントチームにわかれ、進捗管理とリスクコントロールを行います
6.プレゼンテーションとディスカッション
 課題開発の結果のプレゼンテーションを行います
 振り返りを行い、セッション1~5で習得したプロジェクトマネジメントのポイントをまとめます

このように、プロジェクトを実施することに重点を置いていますので、実際にものづくり(ロボットを作る)をするプロジェクトを体験し、そして知識も習得できるような仕組みになっています。

このセミナーは従来の入門か応用、基本か実践かという軸ではなく、プロジェクトマネジメントの「実行力」を養う力をつけることを狙ったものです。実行に必要な知識を身に付けると同時に、実行方法を学ぶことができます。

過去に受講された方から、

> LEGOでロボットを組み立てるという小さなプロジェクトへのプロジェクトマネジメ
> ントの適用を体験することで、プロジェクトマネジメントのポイントが実感できた

と大変好評をいただいております。

過去のセミナーの様子が下の紹介ページにありますので、ぜひ、ごらんください。

◆お申し込み

お申し込み・詳細はこちら。

http://pmstyle.biz/smn/point.htm

LEGOでPMコンピテンシー開発

●プロジェクトマネジャーとしての行動習慣をつけるためには、その習慣(コンピテンシー)を理解し、意識をしながら、とにかく考え、行動してみることである。

●プロジェクトマネジメントオフィスでは

 https://mat.lekumo.biz/pmstyle/2006/07/post_1df9.html

にあるように以下のステップからなるPMコンピテンシーの学習法を提案している。

1)コンピテンシーの理解
2)実経験での認識
3)ソリューションの構築
4)ケーススタディ
5)スキル実践

●この中で、5)はセミナーで行うのは難しく、持ち帰って実践してみてくださいということで済ませていた。しかし、このセミナーでは、実際にLEGOによるロボットプロジェクトのプロマネを経験することで、5)をセミナー時間内で行えるように
なっている。

Project1 ●学んだことをすぐに実践してみることによって、PMコンピテンシーのイメージが明確になるだけではなく、スムーズに実務の中での実践に結びついていくだろう。

●この規模のプロジェクトであれば、WBSの書き方だとか、見積方法だとかいうテクニカルなスキルはあまり必要なく、PMコンピテンシーの本質を感じられるだろう。

●多くの人はプロジェクトマネジメントのテクニカルスキルを重視するが、むしろ、コンピテンシーを高めて、どうしても足らない部分をテクニカルスキルで補っていくという考え方が王道であるし、シニアプロジェクトマネジャーへの近道だ。

●その意味で、シニアなプロジェクトマネジャーを目指す人には最適のセミナーである。また、新米プロジェクトマネジャーがマネジメントのコアスキルを形成するためにもお奨めできるセミナーだ。

◆セミナーのご案内

お待たせしました。昨年から(セミナーの中で)宣言していた7つの習慣セミナーのLEGOプロジェクト版が、ついに登場です。予定より半年遅れた分、充実した内容になっています。

セミナーの流れは以下の通りです。

【Step1】「プロジェクトR」実施
 「プロジェクトR」のプロジェクトマネジメント計画書が与えられ、チームメンバー全員がプロジェクトリーダーのつもりでプロジェクトに取り組みます

【Step2】7つの習慣のレクチャーとエクスサイズ
 Step1のプロジェクトRの振り返りをしながら、プロジェクトマネジャーの身に付けるべき7つの思考・行動習慣について学びます。
 また、ショートエクスサイズで体感します。

【Step3】プロジェクトR2
 ステップ3では新しいプロジェクト「プロジェクトR2」を簡単なプロジェクト計画書の作成から計画実行まで一通り行います。
 その中で、今度は、分担制でプロジェクトマネジャーを決め、Step2で学んだ思考・行動習慣を意識し、実践しながらプロジェクトを進めていきます。

一連の学習の中で、プロジェクトマネジャーに必要な行動習慣・思考習慣が身につきます。目の前にモノをおいて考えますので、まあ、セミナーなので、こんなところでいいやといったいい加減なことはできません。

本物の行動習慣・思考習慣が身につきます!

 ◆プロジェクトマネジメントを成功させる7つの習慣(LEGO)
  講師:好川哲人(プロジェクトマネジメントオフィス)
  詳細・お申込 http://www.pmstyle.biz/smn/compnew.htm

続・プロジェクト監査を理解しよう(2006.7.31)

前回のコラムでは監査の必要な理由と、プロジェクトマネジメントにおける監査の意義を説明した。

 https://mat.lekumo.biz/pmstyle/2006/07/post_5080.html

今回は、もう少し、プロジェクト監査について深く考えてみたい。その前に、少し、監査の基本を整理しておく。

◆監査の主体者

監査の定義は前回述べたが、監査には3つの主体がある。監査依頼者、被監査者、および、監査人(監査員)である。前回述べたように、監査の公正さはこの3つが独立し、健全な関係にあった初めて担保される。これらの言葉は以下のように定義される。

 監査依頼者:監査を要請する組織、または人
 被監査者:監査される組織(プロジェクト)
 監査人:監査を行う力量を持った人

Audit2 ◆誰が誰を監査するか

上のような主体があるときに、監査の種類は誰が誰を監査するかで、第一者監査(いわゆる内部監査)、第二者監査、第三者監査に分けることができる。

第一者監査は内部監査を呼ばれるもので、組織内で独立した監査チームが組織の他部門を監査するものである。ビジネスの中で実施されるプロジェクトの監査はほとんど内部監査になる。

第二者監査、第三者監査はいずれも独立した組織が他の独立した組織を監査する。

第二者の場合には発注者が同組織である。例えば、SIのプロジェクトで委任契約先の活動を発注者が監査することがあるが、これは第二者監査である。

第三者監査は依頼者が外部の監査人に依頼して、組織内の被監査者の監査を行うケースである。このようなケースはビジネスの中では珍しいが、公的性格のプロジェクトではよくあるケースだ。

◆何を監査するのか

監査の内容は大雑把にいえば、2つある。

一つ得られたパフォーマンス(実績)が妥当なものかどうかをチェックする監査である。これが前回述べたコンプライアンスの監査であり、定められた基準に合致しているかどうかが問題にされる。当然、合致していない場合には、不適合となる。パフォーマンスでよく問題になるのは、はやり、変更をめぐるものである。

例えば、15%のスケジュール遅れが発生したら、シニアマネジャーに分析と改善計画を報告するという変更管理ルールを決めていても、結局の正しく実行されないといったケースだ。これは、監査としては比較的分かりやすい。

もう一つはプロジェクトマネジメントシステムが妥当なものであり、それが適切に運営されているかどうかをチェックするものである。

これはシステム監査という呼び方をされることが多い。こちらは若干分かりにくい。システム監査の立場からは、上の問題は必ずしも不適合であるとは断定できない。そのような事実(データ・ログ)が発見された場合、その是正として、バリアンスの大きさに関係なく、1ヶ月に一度、シニアマネジャーに対して報告をするというコミュニケーション計画を追加したとし、この措置によるこの問題は繰り返し起こらないと判断されるので、不適合とは判断されない。逆に、これでもまだ、同じ問題が起こるだろうと判断されれば不適合だと判断される。

◆プロジェクトマネジメントにおける監査の必要性

というインプットの元で、もう一度、プロジェクトマネジメントの監査の必要性について考えてみる。

プロジェクトマネジメントの標準化の最も難しい点は、その標準を導入してもプロジェクトが成功するとは限らないことだ。プロジェクトマネジメントというのは本質的にそのような位置づけにある。プロジェクトの成功を保証するものではないが、やらないよりはやった方がよい。これが基本的な位置づけである。

このような位置づけからすると、パフォーマンス監査は必ずしも重要ではない。むしろ、システム監査を通じて標準の評価とマネジメントの改善をしていく。そこに最も重要な意味があるといえる。

このコラムでは、プロジェクトマネジメント監査については、その必要性を中心に概要を述べた。監査のテクニックについては、別途、本論の中で解説する予定である。

◆関連講座のお知らせ

<PMOリーダー養成講座第4回>

プロジェクト品質を向上させるプロジェクト監査の理論と実際
http://www.pmstyle.biz/smn/audit.htm

2006年8月 2日 (水)

全員参加型のリスクマネジメントをしよう

◆後悔先に立たず

Risk1_3 結果としてみれば、あそこでリスクに気がついていなかったと振り返ることはないでしょうか?このような経験がある場合には、リスクマネジメントきちんと機能しているかどうかを検証してみる必要があります。リスク識別はしているものの、リスクマネジメントは機能していない組織は意外と多いものです。

◆リスクマネジメントの最大の問題はリスクモニタリング

リスクマネジメントの中の最大の課題は、リスクモニタリングにあります。リスクモニタリングでよく見かけるスタイルは、プロジェクトマネジャーだけがリスク登録簿(リスクリスト)を持っていて、定例の進捗会議の際に、めぼしいリスクについて、リスクオーナー(メンバー)に質問をするというスタイルです。

このスタイルが決して悪いわけではありません。リスクマネジメントを最も効率的に(低コストで)実施しようと思った場合にはこのスタイルが適しています。

しかし、冒頭に述べたようにリスクに気がつかずに、トラブルに発展してしまった場合にはこのリスクマネジメントの方法に問題があると考えるべきでしょう。

では、どうすればよいのか?答えは一つです。「リスクに強いプロジェクトを作る」ことです。リスクというのは管理しようと思っても管理できるものではありません。

というよりもプロジェクトのリスクを管理するということは、成果ではなく、人(の行動)を管理することに他ならず、プロジェクトマネジメントのやり方として首を傾げざるを得ません。プロジェクトマネジメントは成果を管理し、人をマネジメントすることだからです。

◆プロジェクトリスクは各人が管理するしかない

そもそも、プロジェクトの中で人を管理できるはずがないのです。だとすると、リスクを管理しようと思えば、一人ひとりのメンバーに自己管理してもらうしかありません。これが本来のPMBOKのリスクマネジメントのあり方でもあります。言い換えると、プロジェクトの中でメンバーにセルフマネジメントを求めるというのは、リスクマネジメントをすることに他ならないのです。

Juggle2_2 もう一つ、メンバーにリスクを管理してもらうことについてはポジティブな効用があります。それは、リスクがプロジェクトの推進力になることです。プロジェクトとしてテンションを上げて、効率的に仕事をするために、リスクの存在というか、リスクの認識は不可欠です。マネジメント的にもこれを積極的活用しないてはありません。

◆関連セミナーのお知らせ

このような背景でリスクに強いプロジェクトを作るセミナーをやります。以下のような内容です。

1.リスクに対する正しい知識を身につける
2.プロジェクトを失敗させるリスクと見落としがちなリスク
2.1 プロジェクトの種類
2.2 プロジェクトの性質
(エクスサイズ)リスクドリル
3.リスク計画書をレビューし、アドバイスする
(エクスサイズ)リスク計画レビュー演習
4.リスクモニタリングを推進する
5.リスクの分類とパターン化、ナレッジマネジメント
(エクスサイズ)リスクパターン作成演習
6.プロジェクトのリスクマインドを高めるための施策

対象者は、メンバーからプロジェクトマネジャー、プロジェクトマネジメント支援者(PMOなど)まで広範です。全員が同じ意識でリスクマネジメントに参加してもらうことによって、プロジェクトを成功に導くというコンセプトです。

チームで参加されるとより有益です!

〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
 ◆リスクに強いプロジェクトと組織を作る
  日時:2006年08月25日 10:00-18:00
  場所:ヴィラフォンテーヌコンファレンスセンター(東京・港区)
  講師:好川哲人(プロジェクトマネジメントオフィス)
  詳細・お申込 http://www.pmstyle.biz/smn/pmo_risk.htm
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

技術を活かすマネジメントの切り札「プログラムマネジメント」

Juggle1 現在のような製品ライフサイクルが短い市場環境の中で、技術をうまく使うということを考えた場合、

 技術ありきでもだめ
 市場ありきでもだめ

で、まずは

 事業戦略ありき

でその事業戦略の中で、戦略を実現するという視点から技術的要素と市場的要素の最適化を図っていって初めて技術をうまく活かすことができるのではないかと考えました。

そのようなマネジメントとしては、自動車におけるマルチプロジェクト戦略が有名です。技術による利益を最大化するようにプラットホームを構築していき、プラットホームにより技術の活用を図るととにも、自動車の開発としては車種ごとに独立した開発マネジメントを行う方法です。

この方法は、製品開発マネジメントの中で研究しつくされ、多くの研究書が出ていますが、必ずしも汎用的な方法ではありません。そこで、この分野での標準的なマネジメントの出現が待たれていました。

そのような中で、2006年6月に、プロジェクトマネジメント手法のグローバルスタンダードであるPMBOKを開発・維持している団体PMI(Project Management Institute)が本年6月に複数のプロジェクトの管理手法としてプログラムマネジメントとポートフォリオマネジメントの標準を発表するに至りました。

これを受けて、今後、製品開発マネジメントの分野でもプログラムマネジメントの普及が予想されます。

Juggle3プログラムマネジメントは、「ベネフィット」に着目し、ベネフィットを最適化するマネジメント手法ですので、製品開発全体のマネジメントの枠組みに最適で、今後、製品開発製品開発プロジェクトマネジャー、プロダクトマネジャーには不可欠なスキルになっていくと思われます。

◆関連セミナー

この機会に、ぜひ、知識を習得されることをお奨めいたします。

〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
 ◆プログラムマネジメント
   ~複数のプロジェクトを同時に成功させる方法とそのポイント
  日時:2006年09月21日 10:00-17:00
  場所:全国農業共済会館3F テクノ研修センター(東京・千代田区)
  講師:好川哲人(プロジェクトマネジメントオフィス)
  詳細・お申込 http://www.pmstyle.biz/smn/mpm.htm
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
【カリキュラム】
1.いかに複数のプロジェクトをマネジメントするか
2.マルチプロジェクトマネジメントに関するPMIの標準
3.プログラムマネジメントの概要
4.プログラムにおけるプロジェクト間のコンフリクトの解消
5.プログラムのプロジェクトのスケジュール管理とリソース管理
6.プログラムのリスク管理
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓