ホーム / リスク管理

リスク管理

ビジネスに自分の目を注ぎ続ける

米国務訂正省ともなれば、システムはできるだけ近代化されているだろうと期待することでしょう。残念ながら、このようなことはほとんどありません。マーク·ピーターソン氏の記事によると、部門内のシステムは、平均20年であったと最近の調査で示していたといいます。これは怠惰や知識の欠如とは何の関係もありません。ピーターソン氏は、ビジネス要件のない定義が存在しないため、そのような問題が発生した、と主張しています。 残念ながら、近代化計画フェーズ中にビジネスと技術的な要件定義の欠如を見続けています。顧

続きを読みます »

プロジェクトを遅らせる必要があるだろうか

ユニークなプロジェクトがその可能性を最大限に到達するために、もう数週間余計に必要とする場合、あなたはおそらくそれを許可する必要がある。では、プロジェクトの納期がすべて時間不足であるときはどうだろう。そんな場合はプロジェクトを延長することになる、とブルース·ベンソン氏は、取るべきオプションについて述べている。 ベンソン氏は、彼と彼のチームが競合より先に製品を市場に投入した最初の方法の話と関連付けている。それはかなりバグが多かったが、利用可能な唯一のオプションであったことと、また本当によく売れたのだ。だが、その後、競合が失われた時間を補って非常に高い品質の製品を出した。ベンソン氏の会社の新しいソフトウェアは、その基盤として最初にバグだらけのソフトウェアであったため、氏とそのチームにとって約束どおりに時期に新製品をリリースするのは難しく、一方、競合はそれを自分に有利に推し続けていたのだった。 ベンソン氏の会社のCEOは製品の配達を高速化することを望んでおり、一方、ベンソン氏は、既に12〜15カ月のウィンドウ内で約束した新製品の提供に対して、平均して18ヶ月かかっていたのに気づいた。彼らは明らかにまだない良い効果にこれをやっていたので、このシナリオでは、ベンソン氏は、プロジェクトの納期を遅らせることは助けになるとは信じていなかった。それどころかベンソン氏は、この解決策を思いついた。 我々は次の製品を通常開始するよりも3ヶ月前にそれを開始したのだ… 何が起こったのだろう。さて、この以前の我々のプロジェクト同様に、大変で危機に見舞われた、完成したときの違いは、顧客が我々の製品を受け入れてくれたことであり、それは約束した時間に間に合い、品質が向上していたからだった。- それも劇的な改善があったのだった。 原稿(英語)はこちらからどうぞ: http://pmtoolsthatwork.com/delaying-projects-lessons-learned-from-electronic-arts/

続きを読みます »

遅延と予算オーバー?プロジェクト管理者の災害の回避の仕方

大規模なITプロジェクトを開始するということは、どこに出口を見つければ分からないまま長い暗いトンネルに入るようなものだ。これは、46億ポンドの資金で英国と仏国を結ぶ海峡トンネルに入って来て、オーバーシュートをその予算の80%で辛うじて管理したようなものである。フィリップ・モスコソ氏とジャウメリ・ベラ・セグラ氏は、プロジェクトのそういった運命を回避するための戦いのチャンスを与えるプロジェクト管理の方法論の適用について、フォーブス誌のために投稿している。 彼らはどのプロジェクトも一般的に、選択、定義、計画、実行監査、および完結行為という5段階のライフサイクルを通過するということが分かった。だが、伝統的なモデルには選択肢がある。会社が低コストの入札者が契約を授与された後で、そのコストを増加させることは、「コスト+インセンティブ費」として検討することができると見なしている。それは以下のように機能する。 顧客がプロジェクトの全体的な責任を保持し、その費用に利益の共有分を足して建築者に支払うこと約束した場合、双方が協働して、機能を向上させ、コストを削減し、作業を速く完了させるような革新的なソリューションの(やる気を起こさせる)インセンティブを作成する。 コストを削減する別の方法は、プロジェクトの側面を、価値を追加するもの、必要だが価値を増加しないもの、必要ではないが価値を追加するもの、タスク間で待ち時間がかかってしまうもの、の4つのカテゴリに分けてしまう。この最後の二つのカテゴリはできる限り外して、重要な支出だけが残るようにする。 原稿(英語)はこちらからどうぞ: http://www.forbes.com/sites/iese/2015/03/09/late-and-over-budget-a-method-to-avoid-project-management-disasters/

続きを読みます »

容易な4ステップでプロジェクトのパニックを回避

あなたは優秀なプロジェクト・マネージャであるかもしれませんが、遅かれ早かれ、頭上に入り込むようになります。その時間が来ると、頂点に立っている間は、ありがたいことにパニックを進むのを助けるステップがあります。ケニス・ダータは、攻撃の計画を展開する記事を書いています。 トラブルの状況では、最初のステップは穏やかなままです。あなたが当惑したと感じるときは、通常は、手元にある課題の不可解さに起因しています。その心配の種を追い払うには、その問題を理解できて管理できる部分に分割しなければなりません。 次のステップは、助けを求めて手を伸ばすことになります。あなたがそれを実行している間には、絶望的だと思われないことを覚えておいてください!明快さと自信をもって、「チャレンジ」(「問題」ではない)を同僚に取り継ぎます。自分自身の理知的な声で伝えられている問題を聞くことで、いかに冷静になっているかに驚くでしょう。 パニックを避けるという現実の仕事は、チャレンジの再構成を含むために、積極的な変更に資するようになります。もちろん、1日や1週間でも、これを達成できない場合もあります。プロジェクトの予定を書き直すことは、一例です。それでもなお、無条件に必要なことだけに焦点を合わせるのがまず最初です。他の全部は、待つことができます。 最後に、あなたはチャレンジを克服するための接合点に到達します。おそらく、適切に管理してあれば、いくらかの新たな技能、より良い製品/サービス、ただ単に新たな展望をもって、切り抜けます。いずれにせよ、それはしばしば最も大きな報酬をもたらす、最も困難な障害です。 最初の記事をお読みください(英語)。 http://www.projectsmart.co.uk/getting-in-over-your-head.php

続きを読みます »

7 つの致命的なプロジェクト管理問題

一貫して問題を処理する方法を知っているプロジェクト管理者(PM)は、何年もの間その職業に就いて成功している。残りは、ショパンの「葬送行進曲」からの脱出が必要になることもある。ジェニファー・ロノーフ・シフ氏は、PMが解決すべき7つの最も重要な問題を定義して、その障害を設定している。 説明責任 リソース 締め切り スコープ サプライズ 距離 コミュニケーション 予想は始めから確立されるべきである、とシフ氏は述べている。RACI(責任、説明責任、相談、通知)チャートを用いることによって、PMはプロジェクトの役割についてスタッフに責任を持たせるために必要な構造と可視性を与えることができる。 締切は、より普遍的な問題であるが、PMにとっては全く新しい次元となる。セ キュリティアウェアネス社の生産ディレクターであるアシュリー・シュバルタウ氏は、チームメンバーのために人為的に事前にそれらを設定し、時折起こる失態 や見直し用の緩和剤として残すことによって、期限を扱っている。もう一つの一般的な問題は、スコープクリープだ。良いPMは変更、検証、資産、および影響の徹底的なドキュメントを保持する。優秀なPMならば、さらにそれより進めて、リスクと品質管理戦略を実装することだろう。 それに、サプライズという要素がある。この場合、PMが持つことを望むものでは ない。定期的な状況会議は歓迎できない混乱を避けるには十分であるが、その次に賭けるとしたら共同作業トラッキングソフトウェアがいいだろう。第六番目の 項目について、チームは国内や世界中に分散されている。ここでの解決策は技術だ。適切なモバイルの共同ツールを使用すれば、距離の制限が克服される。そし て最後に、チームに調和が欠如しているなら必然的に最良の開発プロジェクトでも取り消しになりうる。ここでの修正は、通常の電話相談や直接訪問を通して チームメンバーと係合し続けることだろう。 元稿(英語)はこちらからどうぞ: http://www.cio.com/article/2876701/project-manager/7-ways-project-managers-can-anticipate-avoid-and-mitigate-problems.html

続きを読みます »

プロジェクトマネジャーが犯す3つの大きな過ちとは?

プロジェクトマネジャー達は、プロジェクトチームのやる気を引き 出すこと、プロジェクトの利害関係者から協力を勝ち得ること、自分たちの努力にふさわしい結果を得ることに今もなお苦心していることが分かったと、プロ ジェクトリーダーシップのコーチを務めるスザーン・マッドセン(Susanne Madsen)は述べています。マッドセンはブログの中で、通常であれば非常に知能的に高いプロであるプロジェクトマネジャーでも苦心の種となる3つの大きな過ちを挙げています。 最大の過ち プロジェクトのチームメンバーを率いるのではなく、プロジェクトのタスクを管理してしまう 焦点が重要課題ではなく緊急を要する問題点に当てられてしまう 全ての問題点の解決に対応してしまう プロジェクトマネジャーがタスクを割り当ててスケジュールを作成することに集中すれば、そのプロジェクトは多分に成功することになるでしょう。しかし、何故このプロジェクトは重要なのかだとか、実際の人たちにどんな影響を及ぼすのだろうか、などとプロジェクトマネジャーが考えめぐらしたりしていると、誰か他の人によって創り出されたビジョンをプロジェクトを通して形あるものにすることではなく、ただ単にビジョンを実行することだけになってしまいます。 プロジェクトは期限厳守で遂行されるものです。集中力が奪われて しまうような問題点が発生すると、本来焦点を当てなければならない問題点に対する注意集中が置き去りにされてしまします。プロジェクトマネジャーは、翌月 のプロジェクトを正式に戦略化しなければならない時間を確保しようするがために、イーメールされてきた緊急の問題発生を無視することに罪悪感を感じるかも 知れません。しかし、マイナーな問題点が発生する度に果敢にそれらの問題点を回避しようと努めることによって「忙しそうに見える」という悪循環に陥ってし まうと、プロジェクトを苦しめるより深い問題点に対応するための時間を確保することは何時まで経っても永遠にできないくなってしまうでしょう。 もう一つの共通の過ちは、プロジェクトマネジャーはすべての回答 を欲しがり、すべてをコントロールしたがることです。このような進め方をすると、プロジェクトマネジャーはあらゆる決定を同時にすることになってしまい、 疲労困憊してしまうことは避けることはできません。更には、このようなやり方は、プロジェクトチームの個々のメンバーが自ら問題を解決し、全体の負担を 個々が負担するという理想の姿とは裏腹に、プロジェクトマネジャーから次の指示が来るまで何もしないで立っているというように、チームメンバーから個々の 権限を奪ってしまうという逆効果を生む結果となってしまします。 原文(英語)を読むには:http://www.pmhut.com/what-are-the-3-biggest-mistakes-that-project-managers-make

続きを読みます »

自分自身にウソをつくことを止める: リスク許容度の測り方

リスクを避ける、移転する、軽減する、又は受け入れる、等いずれかを決定する場合でも、全てのリスク対応戦略にはコストのリスクと内在 するリスクの二つが存在します。リスクを回避することは、通常の場合、機会コストをもたらす結果となるか、少なくとも利益が繰り延べられることになります が、内在するリスクは最小となる傾向にあるようです。例えば、スケジュールのリスクに対応する場合、スケジュールの範囲からある要素を取り除こうとするこ とは、リスクを回避することに当たりますが、この場合、その要素がもたらし得る利益を享受することができない機会コストが発生することになります。 リスク対応戦略の選択 私がこのことをここで論じる理由には、回避するか移転することができるようなリスクを軽減するか受け入れるこ とを選んでしまう組織や管理者が非常に多いことが挙げられます。それはより安全な対応策の認知コストに関することであるような場合も中にはあります。しか し、多くの場合は、異なる文化が混ざり合い、展開した後でたどり着く最終地点にまだ到達していないような吸収や合併が発生している組織の中に見ることがで きます。吸収合併以前の会社の一方はリスクに対する選好度がより高いかもしれませんし、中間管理職は吸収そのもを既に自分たちの中に取り入れてしまってい るかも知れません。或いはある特定の種類のリスクに対してはもう一方側の同僚たちよりも選好度がより高いのかも知れません。 昨年、私は、自分の会社よりも大きな会社に買収されようとしている会社と私の顧客として仕事をする機会がありました。その会社では、あ る一つの法的要件に順守していない状況が発覚する可能性を軽減することの目的のために、それが発覚することの可能性はほとんどないような状況だったにもか かわらずに、わざわざそのためにプロジェクトをスタートさせました。このプロジェクトのコストは、順守していないことが発覚した場合に発生し得るコスト や、既存のマニュアルのプロセスを改善するコストよりもはるかに高く付くものでした。しかし、このプロジェクトを決定した人にとっては、順守していないこ とのリスクを絶対に軽減しなければならないと思っていました。しかしながら、このプロジェクトはスケジュールと質の面からは非常にリスキーなものでした。 そのプロジェクトはその後開始されましたが、その会社はプロジェクトのキーとなる職務に比較的経験の浅いチームメンバーを任命し、その上、そのプロジェク トを遂行する上でどのような業務規定に沿うべきなのかについての社内コンセンサスが全くありませんでした。結局のところ、買収側の会社の経営幹部はこのプ ロジェクト廃止してしまいました。さまざまなリスクを一つにまとめたリスク全体に対する考え方が買収側の会社では大きく違っていましたし、内在するリスク のすべてに対応するのではなく、比較的コストが低く、影響度の小さなリスクとして受け入れてしまうことを決定したのです。 リスク選好度を測る リスク許容度を測ることは非常に難しいことであるし、それを意味のある言葉で説明することは更に難しいことです。あるインタビューの中で、私はプロジェクト管理室(PMO) の責任者にその方の組織のリスク許容度について尋ねたことがあります。その方は、そのような質問をされたことは今まで一度もなかったと言い、契約プロジェ クトの管理者としてふさわしい回答を見出すことに苦心していました。率直に言うと、どのレベルのリスクであれば許容できるかを説明できる人はほとんどいな いですし、リスクはまったく好まないと自ら認めるような組織はないということです。しかし、一まとまりのさまざまなリスクのコストを最適なレベルのものに することのできる能力は、組織が別の選択肢をどのように評価するかを理解できているかどうかによります。以上から、、リスク許容度を測るプロセスを始める ためのいくつかの質問を以下のように列記したいと思います: コストを軽減するためには、新規仕入先と進んで契約を結びますか? はい、であれば、リスク許容度がある程度高いと見られます。 自分の部下を増やすコストを削減するためには、派遣社員を雇うことによって離職率が高くなることを敢えて受け入れますか? はい、であれば、リスクをより進んで受け入れるタイプになります。 スケジュールどおりに完了するためには、質のリスクがより高くなることを進んで受け入れますか? もしプロジェクトが定められた完了日がない場合は、リスク許容度が高いことを示しています。 操業費を低く抑えるためには、設備費がより高くなくことを進んで許容しますか? はい、であれば、リスクを移転する意思と見られるかも知れません。 スケジュールのリスクを軽減するためには、完成させるものを進んで遅らせますか? はい、であれば、リスクを回避する意思と見られるかも知れません。 実行するリスクを軽減するためには、進んでプロジェクト管理をさらに複雑にしますか? これもリスクの移転に当たります。 上記リストは、特に全てを網羅しているものではありませんが、組織のリスク許容度についてある程度理解できるものと思いますし、或いは最低でも、提案されたプロジェクトに該当する組織の許容度を理解できるものと思います。

続きを読みます »

ITプロジェクトが失敗する3つの要因

ITプロジェクトに対するビジネス要件は、「永遠に続くものを作り上げる」から「変更できるように設計する」へと目的が変わり、その結果、状況が複雑化してしまい、プロジェクトが憂慮すべき頻度で失敗する事態が生じています。パール・チュー(Pearl Zhu)はブログの中で、プロジェクトの失敗は3つの根本原因に起因するとしています: スポンサーのエゴ ロスの忌避 確率の無視 スポンサーというものは往々にして、成功する可能性を犠牲にしてでもプロジェクトが失敗しないように舵取りをしようと試みるものです。その理由はただ単にリスクを避けるという単純なものであるかも知れませんし、或いは、スポンサーが個人的利益を得る目的でプロジェクトを操作しているためのものであるかも知れません。別のシナリオとしては、プロジェクトのスポンサーが全ての必要とされる変更に喜んで関与し、監督するけれども、それは最初のうちだけというような状況です。それは、時間が経過するにつれて、スポンサーのプロジェクトに対する興味がその意気込みと後押しと共に薄れてしまうというものです。 顧客のためにプロジェクトを成功させると言うことは、言うは易し行なうは難しです。成功するための適切な物差しなくしては、プロジェクトチームは暗闇の中で火を灯すようにもなります: 必要とする要件、プロジェクトマネジャー、悪しき規範等々全てを列挙することはできますが、結局のところ、次のような3つの要因が絡み合ってプロジェクトは失敗に終わります:専門知識の欠如、停滞した又は時代遅れのIT能力、そして会社全体にわたるコミュニケーション体制が機能していないことが挙げられます。 ITプロジェクトの30%が完全に失敗すると推定されています。またプロジェクトの70%までが顧客の期待に応えることができないとも言われています。プロジェクトのリスクを適切に分析することは、失敗を防止するための第一のステップであることは勿論のことです。結局のところ、信じられないことが実際に発生してしまうことは避け得ないものであると言えるでしょう。 原文(英語)を読むには: http://futureofcio.blogspot.com/2015/01/three-aspects-of-it-project-failures.html

続きを読みます »

ITプロジェクトを打ち切るのは最後の手段としてのみ

それはプロジェクトマネジャーが考慮する最後の手段ですが、プロジェクトがコントロールできない状態に陥った場合は、最初に考慮されなければならないことです。メリー・シャックレット(Mary Shacklett)は何時の時点で問題となっているプロジェクトを打ち切るのかについて書いています。とは言え、関係者に打ち切りを告げる以前に、その問題のプロジェクトを生かすことのできる次善策や予防対策を考えることが必要です。 大きなプロジェクトが倒れてしまうことはよくあることです。いつのかの時点において、プロジェクトマネジャーは関係者に対して、「事態は悪くなっています。しかし、この破滅状態を救うためにできることはあります。」と勇気を持って告げなければならない時があります。思慮深いプロジェクトスポンサーであれば、状況を理解しプロジェクトマネジャーと共に事態を切り抜けようと試みるものです。 危機に陥っているプロジェクトを再起動させるための別のアプローチとしては、まずプロジェクトを前に進めることを一旦停止し、少し時間をかけてプロジェクトであるソフトウェアをバーチャル化してみることも挙げられます。バーチャル化することによって関係者に最終製品が現実的にどのようなものであるかを見てもらうことには多くの利点があります: 最終ビジネスユーザーが完成したソフトウェアの「承認テスト」を実施する時点になると、テストの後でITのところに戻って来て、「これは我々が期待していたものとは全く違うではないか!」と言うような場合は結構あるものです。そのような時点までには、相当の予想と期待が既にでき上がってしまっていますので、プロジェクトマネジャーの進退問題にもなりかねません。 現実には、ソフトウェア開発プロジェクトの実に45%が目標を達成することができていません。ソフトウェアが完成する以前に、プロジェクトのスポンサーにソフトウェアが完成した場合の姿を簡単に説明しておくだけでも、相当の時間と様々な資源を節約することが可能であることを考えてみると、このような統計は非常に破滅的なものであることがわかります。 原文(英語)を読むには: http://www.techrepublic.com/article/pull-the-plug-on-an-it-project-as-a-last-resort/

続きを読みます »

リスク管理: 何を、何故、及び方法

先を見越したリスク管理をする時に来ています。それは、結果を前もってコントロールしようとすることを意味しています、とマイケル・スタンレイは書いています。最善のリスク管理であっても、ある特定の結果を保証することは不可能ですが、少なくとも起こり得るネガティブなインパクトを和らげることはできると言えるでしょう。 実際には、リスクを管理することは初心者の段階に過ぎません。プロのレベルにある専門家は、リスクを適当に数量化し想定されるインパクトを描き出すというダイナミックなシステムに基づいたリスク管理を行っています。潜在的なリスクが特定されると、チームはこれまでのデータ、過去の実績、及び直感を含む様々な要因に基づいて一つ一つのリスクに優先順位を付けていきます。スタンレイは更に次のように述べています。 …機会とリスクは通常プロジェクトの計画の段階では相対的に高いところにあります…しかし、この時点では投資は相対的に低いレベルにありますので、リスクとなる金額はまだ小さいままになっています。逆に、プロジェクトが実行段階にあるときは、未だ不明とされる事柄が判明されるに従い、リスクは漸次そのレベルが下がっていきます。同時に、プロジェクトが完了されるために必要なリソースが漸次投資されるに従って、リスクとなる金額は上昇していきます。 あなたのチームがリスクに対応するようになった時点では、3つのオプションがあります。リスクの原因を取り除くことによってリスクを排除すること、リスクが発生する可能性を低くすること、又は、リスクの可能性を受け入れ、リスクが発生した場合のリスク管理計画を準備することが挙げられます。 原文(英語)を読むには: http://www.pmhut.com/risk-management-the-what-why-and-how

続きを読みます »