ホーム / プロジェクトポートフォリオ管理

プロジェクトポートフォリオ管理

プロジェクトのポートフォリオのコストについて質問するのが間違っているわけ

今、最もお金が稼げるのは何でしょうか。それはついつい尋ねたくなるような魅力的な質問です。人はプロジェクトから即、金銭的な結果を見てみたいと願うものです。しかし、それによってどれほど儲けがあるかではなく、プロジェクトの価値について自問する必要があります。 ヨハンナ・ロスマン(Johanna Rothman)氏は、プロジェクトのポートフォリオが組織に最善の長期的な結果を生み出すには、変化させる必要があることを念押ししていれます。そう、プロジェクトには企業に金銭を生み出してくれるので保管しておくべき

続きを読みます »

ポートフォリオ管理者のすべきこととしてはならないこと

あなたは今までにポートフォリオの管理者が実際に何をするかを理解するのに苦労したことがありますか。ITの世界における多くの地位と同様に、タスクは多く、定義は幅広いかもしれません。しかし、上級レベルのプロジェクトの幹部でも、また The Standard for Portfolio Management (ポートフォリオ管理の標準)– 第三版を著した、ジェンL. スクラバック(Jen L. Skrabak) 氏は、我々のためにポートフォリオ管理ですべきこととしてはいけないことを分けて教えています。

続きを読みます »

問題を抱えたポートフォリオ、問題を抱えたプロジェクト

プロジェクトに問題があるとき、ご自分のポ゚ートフォリオが健全であるかを分析することは最善なことです。隆々たるポートフォリオは、協調性と関連プロジェクトの配列如何にかかっています。好ましくないポートフォリオの環境は、ポートフォリオの有り方を会社が教育していなかったこと、(つまり、ポートフォリオはプロジェクトの量が多いから作れるものではないということ)に起因している場合があります。 ポートフォリオに問題がある場合の兆候: 何度も問題を抱えたプロジェクトに直面している プロジェクトの30%以上に問題

続きを読みます »

ビジネス上の知性と戦略的決断の間の切断

Kailash Awati氏はその投稿ブログで、現時点におけるビジネス·インテリジェンス(BI)は、戦略的意思決定を行うには不向きだと述べている。彼は、BIが未だに運用事項を測定して管理するための手段として厳密に使用されていると信じている。 BIとビッグデータと予測分析間には平行線が引かれていて、戦略的な意思決定を行うのに何ら提供することができないにも関わらず、運用の意思決定に向けてすべてがうまく行くようになっている。 従来から意思決定のプロセスは、使用可能なオプションを識別し、各オ

続きを読みます »

プロジェクトのポートフォリオを管理するための4つの秘訣

IT管​​理の他の側面ほど、より多くのバランスや、状況の変化に対するより多くの注意深さ、またはプロジェクトポートフォリオ管理に多くの隠されたリスクを伴うものはない。プロジェクトの成功率が現在64%で失速している場合の、プロジェクトポートフォリオをより良く管理するための4つの便利なヒントをジェン・スクラバック氏は提供している。 持続可能なプロジェクト/プログラムを選択する ポートフォリオの上限を知る ミスを認め、迅速に調整する 自らの平均値を測定する 組織の強みと弱みに合うプロジェクトの目標を選択する。計画の予定に当たっては、過度に楽観的にならず、現実的になること。また、企業の文化がサポートしていない場合は、熟考を重ねたプロジェクトですら依然として拒否されることがあることを心に留めておく。特に短期間におけるプロセス変更で数百人を含む大規模なプロジェクトを扱う場合は、変更管理を忘れてはいけない。 スクラバック氏はまた、「2015年にポートフォリオの投資収益率で1億米ドルを達成する」等の静的な目標を超えた、可能性の数字を伸ばすことを意味する、ポートフォリオの「上限」内で動作するように助言している。 ポートフォリオの上限は、予算、能力(スキルや知識)、容量… または文化(既存のプロセス、変更に必要な組織的機敏性と食欲)によって定義できる。 基本的には「最高のリソース消費期間」を目指し、初期のランプを超えた上限を計画する。 但し、プロジェクトがうまくいかなかった場合はどうだろう。そんな場合はスポンサーにそれをキャンセルするように薦める備えがあるだろうか。プロジェクトの健全性を判断するためには、明確な財務パフォーマンス監視は重要だ。スクラバック氏は、プロジェクトのコースを修正せざるを得なくなるような大変化が急に発生し、敏捷性を要することも起こりうる、と警告している。 最後に、ポートフォリオとは当然のことながら、一つではなく数多のプロジェクトを意味する。時間をかけて、最も実値が作られている所を発見するために、大小のプロジェクトを検証すべきだろう。 元の投稿 (英文) はこちらからどうぞ: http://www.projectmanagement.com/blog/Voices-on-Project-Management/12945/

続きを読みます »

プロジェクトのコンテクスト(前後関係):重要な投資家の区別

動物園のゴリラは完璧な本能的感覚を持っている。ところがあなたの家のソファに座っているゴリラとなると、完全に別の話だ。そんな状況は、特にプロジェクトやポートフォリオ管理では、全く別の光を当てると、我々が理解し再導入していると思っている事とは別の形態になりうる、とリッチ・モルツマン氏は指摘している。 電子メール、積極的な傾聴、頻繁な状況の更新はプロジェクトに関するコミュニケーションのすべての重要な基礎であるものの、それらのどれも優れた前後関係の提供ほど重要ではない、とモルツマン氏は見ている。これは、前後関係は、話している事が誤解されない唯一の保証となる錨であるためだ。さらに、氏は 詳述している。 これは、メッセージのフォーマット(型式)とメディアに配慮することを意味する。また、先ず視聴者が誰であるかを確認した上で、その視聴者にオリエンテーションを提供することを意味する。さらに、競合しているニーズとの前後関係と背景の量のバランスを取る上で簡潔かつ明確にし、見下されることを回避することを意味する… それは、あなたのプロジェクトの必要性を企業のポートフォリオの必要性とのバランスに合わせる事を意味するが、あなたがプロジェクトで手渡しする成果物よりも、彼らの視点からすると、それは性質上長期のものであり、総合的な可能性を持っていることを意味している。 さらに、操作部に製品を渡す時とは対照的に、その製品が安定した状態で存在していると見なすように、続けていくつかのポイントを忠告している。先ず、当然ながらあなたの投資家を知ることから始める。次に、早く表示されるようにメッセージをフロントロードし、サポートでそれを強化する。通信の媒体によっては、本質的に情報の指定されたタイプを中継するのに他のものよりも有用なものもあることを認識する。書かれた通信物の使用に当っては、それを送信する前に、必ず二度読みして、どの人にもそれが理解されるかを確認する。テキストをハイパーリンクして、追加の文脈を提供する簡単な方法もある。 元の投稿(英語)は、こちらからご覧ください: http://www.earthpm.com/2014/11/we-put-the-x-in-context/

続きを読みます »

プロジェクトを選択し、実行に移す良好な方法

<p>あなたの会社の未来は近くにある。正しいプロジェクトを選んで、実行に移すと、最大のポテンシャルに到着する。正しくないプロジェクトを選んでしまうと、競争相手に追い越されて、あっと言う間に失敗におわる。私は何年もの、会社が選択過程で苦労することを見ている。どのプロジェクトを選び、そして、それらを実行させるための資源があるのか。 悲しく、一般的なストーリー これはよくあるシナリオである。幹部は現在の商品を改善し、競争相手を追い越す大きなアイディアがあり、プロジェクトの応援側が半年の期限を宣言した。   プロジェクト・マネジャーが半年以内にプロジェクトを達成させる情報が足りないと心配する旨を伝える。しかし、応援側は選択肢がないと言う。ベストを尽くせと。 プロジェクト・マネジャーは対象の商品について、不明のままプロジェクトに取り組む。プロジェクトのスポンサーは多忙で消極的である。プロジェクトチームがプロジェクトを分析し始め、具体化を図る。チームの2、3人のメンバーは要件を決めようとする。他のメンバーは要求された成果を生み出し、他にチームに試験させる。 プロジェクトチームは何ヶ月に渡り、平日の夜も週末も関係なく、仕事にのめり込む。チームのメンバーはストレスを感じる。会社はかなりの残業代を払い続ける。びっくりすることに、チームは期限に間に合うようだ。 講師は講習を始める。最初の2回分の講習に、ユーザーは初めて、改善された商品を目にする。ユーザーはうめき声を発し、慎重かつ批判的なコメントをする。彼らが関心ごとを機能するマネジャーに伝え、さらに指揮系統に渡っていく。パワフルで影響力のある関係者はチェンジを求めるべく、プロジェクトのスポンサーを呼び始める。スポンサーは商品の変化には4ヶ月が必要となることを見つける。 プロジェクトの選択過程は大変に大きい課題で解決策は人によっては、異なるかもしれない。これは心配無用、決して解決できない訳ではない。下記に成功率をアップさせる習慣を幾つか書いてある。 プロジェクトを選択し、実行に移す良好な方法 プロジェクトのスポンサーを積極的に活かせる。不在のスポンサーでは成り立てない。 プロジェクトチームのメンバーは、戦略的な洞察力に、プロジェクトを成功に導く権力が足りない。スポンサーはチームが思い通りに進行し、必要な資源がある事を確認できる。 プロジェクト選びにプロジェクトの委員会を設ける。プロジェクトの申し込みは認可を得るために、委員会に提出される。 さらに、プロジェクトのスポンサーが、委員会に対して、プレゼンをすればいい。質問があれば、それに答える。 プロジェクト選びの基準を決めよう。どの様にして、プロジェクトを抜擢するかを、組織に伝える。基準を定めて、組織にそれを伝えることで、無駄な時間を削減できる。プロジェクトのスポンサーは失敗作のプロジェクトに時間をかけなくても済む。選択の基準となるのが、(1)戦略的な重要性、(2)規正遵守、(3)経済力の在りか(4)将来の変化にともなうビジネス及び技術的な柔軟性等、である。 プロジェクトの認可に必要条件を定める。出発点としていいのが、プロジェクトの認可書をプロジェクト委員会に提出させる事。認可書とはビジネスの内容、計画の問題点、目標、成果、制約、仮説、関係者、チームメンバー、最高のリスク等を明らかにした手短な書類である。 予備プロジェクトの認可を与え、対象の商品とプロジェクト範囲が決まった後に、さらなる情報を求める。プロジェクト範囲を決める管理過程にはプロジェクトと商品を定める要件を集めることが含まれて、そして、プロジェクトを成果の段階に分解させる。範囲決定とは発見の旅でもある。プロジェクトチームがプロジェクトを解析する段階で、チームには難関と機会がはっきり見える。関係者がかかわり、異なる視点が考慮される。 プロジェクト範囲を関係者に確認させる。範囲の管理プロセスには完成したプロジェクトの成果を正式に受け入れることを含める。サプライズを好む人がいない。適切な関係者にプロジェクトの成果を調べ、受け入れさせる事。 時間の経過とともに見積もりの改良。プロジェクトの範囲が決まる前に、会社の幹部は対象のプロジェクトが完成されるまでの時間を予想したがることが多々にある。プロジェクト・マネジャーには情報が足りない場合は、対象の商品とプロジェクト範囲が決まった後に、より詳細な見積もりがある合意のもとに、早期な高いレベルの見積もりを提供したがる可能性がある。 適切なアプローチを選べ。対象のプロジェクトは理解があるのに、望む時間内 に完成不可能だった場合は、範囲を縮めるか、増加的または段階的なアプローチを設定するか(一塊ごとでプロジェクトを提出するとか)または、アジャイル(Agile)方法を用いる。本プロジェクトは理解がない、または決まっていない場合は、アジャイルをよく考える事。商品のバックログにある、ユーザーの話を掴むことで範囲を決め、反復して、増加的に実施させる。 より良好な会社に 殆どの会社は効率的かつ効果的に決断をくだすのに四苦八苦するであろう。あなたの会社がより早く、よりベターにプロジェクトの決断をくだす事で、競争的に有利になる事を想像してごらん。そうなる可能性もあるが、それなりに行動しなければならない。 計画し、実行に移す。 評価し、必要なチェンジを入れる。

続きを読みます »

サービス戦略およびサービスポートフォリオ

P.ロスS.ワイズ(P. Ross S. Wise)教授は、戦略から実行に至るまでのサービスポートフォリオのプロセスを非常にうまく分類している。ビジネス価値をボールに例えている。ボールをキャッチャーのミットに投げる前に、よく考え抜いた投球戦略とワインドアップが必要である。 サービスポートフォリオ管理の目標は、潜在的な投資家に目を向けるばかりでなく、見送らなければならないサービスにも目を向けながら、ビジネスを提供するための最適なサービスの組み合わせを決めることにある。サービスポートフォリオはまた、コンセプトから寿命の終わりに至るまでの人間、プロセス、技術、及び情報に関する歴史的記録の類として機能するものでもある。それは管理職が大きく変化するプロセスを可能にする戦略的意思決定のためのプラットフォームである。ポートフォリオの審査過程においては、一つの提案は、製品設計の段階に向かう前に、定義付けされ、分析され、承認され、そして許可されるものである。 サービスポートフォリオは、管理者が個々のプロジェクトにおいて自分たちへ投げ掛けられた価値を捕らえることができるようにするものである。しかし、プロジェクト管理とは違い、サービスとはスタートはあるが予見できる終わりがないゲームである。一つのサービスは、ビジネス目標と常に合致していること、および過大なリスクを引き起こすことがないことを確認するために、継続的にモニターされなければならない。 サービスポートフォリオ管理の価値は、ITとビジネスの目標を結び付ける、ITサービスのインパクトに関する貴重な識見を提供する、ITサービスだけではなくスタッフの生産性を向上させる、統合/増強/除去によりコストを軽減する、ITがビジネスの要求に見合うよう手助けする、そして、ブランドの確立を通して業界の世評を高めることができる等々の能力の観点から定義づけすることができる。 原文(英語)を読むにはhttp://www.itsmprofessor.net/2014/09/service-strategy-and-service-portfolio.htmlを参照下さい。

続きを読みます »

情報テクノロジー(IT)の価値をビジネスに当てはめる

テクノロジーがどのように採用され、支援され、そして支払いを受けるかについての予測を立てる上において、サービス・ポートフォリオは最高情報責任者(CIO)にとって有効な手段となるものである。マーク・ハリス(Mark Harris)は、優れたサービスを最小のコストで供給しようとする働きが如何にしてITをビジネスにより緊密に結びつけるかについての一般的な知見を披露している。 ITサービスに関するカタログは、ビジネスに対するITサービスのコスト対価値を示す上で最適である。このようなサービスが高コストで低い価値を提供するものであれば、特定のサービスに対して見直し、リモデリング、或いは中止が求められることになる。勿論、正式なサービス製品を作り出すには、データセンターを流れる電力や冷却などの非伝統的なコストを数量化したり、使用されるサービス要素のコストを原価償却することなどが求められる。 回復機能を持つデータセンターの冷却コストだけでも、総購入コストの半分にも匹敵するのである。そのため、サービスカタログには購入およびライセンスのコスト以上のものが反映されなければならない。ここに、データセンターインフラ管理(DCIM)の必要性が生じるのである。ハリスは以下のように説明している: 基本的には、総合的なDCIMが展開されている場合を除き、どのようなサービスでもその真の供給コストを正確に決定することは不可能である。DCIMは、生産される機器のライフサイクルを管理する上において極めて緻密な手段を提供するものである。DCIMは、初期プロビジョニングから最終廃棄に至るまでのデーターセンター内にある機器に関わるすべてのコストを管理するすることが可能になるソルーションを提供するものである。 IT価値をビジネス価値に結び付けるには、サービスカタログと頑強なDCIMとを組み合わせることが最良と思われる。 原文(英語)を読むにはhttp://www.governmentciomagazine.com/2014/09/exposing-it-value-businessを参照下さい。

続きを読みます »

デザイン思考を通じて技術革新を発見する

ポートフォリオ管理のためには、どのようにして抽象的なアイデアを実用的な応用に変換することができるだろう。ジェン・スクラバック(Jen Skrabak)氏は、最も華麗なアイデアは実験と忍耐を伴う反復プロセスの結果であるため、その「突破口」のイベントとして、技術革新の概念を放棄するように、と助言している。スクラバック氏は、他のものより上に、プロジェクトやプログラムを識別するいくつかの重要な考慮事項を提示している。 1。ポートフォリオ管理者が物事を始める最適な場所は、既存のアイデアや技術革新である。業界の残りの部分が「そこにあって」実践しているものは何か。既に機能している車輪を再発明することには意味がない! 2。変更を求めた探求は十分徹底的に為されていない。革新には、識別、優先順位づけ、そして最終的に最大の正の価値をもたらし、まだ未踏のあらゆる可能性のまとまりから選択したものをオプションとして設定することを目標とすることだ。 3。スキラバック氏が指摘するように、技術革新は革命をもたらす傾向があるものだ。しかし、だからといって、技術革新が完全に新しいという意味はない。時には既存のアイテムを斬新な方法で組み合わせることが必要なだけだ。 4。あなたの最高の意図にもかかわらず、そのアイデアが失敗することも大丈夫だということを忘れないでいよう。時には、反復法で失敗したアイデアの集りが成功のための基礎ともなることもあるのだから。 スキラバック氏は、「技術革新キャンバス」と氏が専門的に呼んでいる作図法を、複数のセクションと併せた使用を、ポートフォリオ管理者の新しい技術革新のためのケースに準備して役立てるように推奨している。 元の原稿(英語)はこちらからご覧ください: http://blogs.pmi.org/blog/voices_on_project_management/2014/08/finding-innovation-through-des.html

続きを読みます »