ホーム / リスク管理

リスク管理

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

続きを読みます »

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

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

続きを読みます »

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

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

続きを読みます »

プロジェクトの複雑さ:プロジェクトを台無しにする変数の監視

プロジェクト管理にあまりにも頻繁に起こることは、一つの単純なモデルを選択し、すべてのプロジェクト管理に適用させることである。プロジェクト管理者がこんなアプローチを使用すると、すべてのプロセスにそれが完全で平等に使用されることになるので、すべてのプロジェクトの実装は即座に支障をきたし始めてしまう。モデルが単純過ぎるということは、判断力が無く、分析力も無く、ツール使用のずれ弾性率も無いということになる。 モデル 対 現実 理論的には、すべてのツールとプロセスは適切であるので、それらを使用することは合理的な選択となるはずである。また、それはプロジェクトをビジネスの方法論に完全に準拠させるはずだ。ところが残念ながら、そんな盲目的な実装では、プロジェクトに適応する柔軟性は欠けてしまう。 我々は、プロジェクト管理の美しさは、異なる分野で、異なるコンテキストにおいて、異なる大きさのプロジェクトのために使用され得ることにあるのを知っている。それは、大規模な建設プロジェクトや、ソフトウェアデザインプロジェクト、技術革新的なプロジェクト、あるいは非常に小さなチームによる研究調査でもありうる。このように、プロジェクト管理理論は、プロジェクトの非常に広い範囲に有用であるように明確に設計されている。 しかし、それぞれのプロジェクトにはユニークで独自の要件が独自のコンテキストに内在している。プロジェクトの成否は、そのコンテキストの現実内で起こる。我々のプロジェクト計画とアプローチを現実に合わせて設計することは重要だ。 すべてのプロジェクトが同じプロファイルを持っているわけではない。すべてのプロセスを盲目的に適用することは、プロジェクトのあらゆるコンポーネントが複雑だと仮定していることになる。 プロジェクトの複雑さの評価 戦略的なプロジェクトリーダーとして、扱っているプロジェクトの複雑さを理解することは不可欠だ。それによって、適切なプロジェクト計画の開発に役立ち、プロジェクトチームを作成し、監視と進行を制御するアプローチを最適化することができる。 非常に類似したプロジェクトを幸運にも実行することもできる。それでも、まだ2つのプロジェクトがまったく同じであることは、非常に稀であることを注意しておこうと思う。各プロジェクトの複雑さのプロファイルは異なっている可能性がある。仮定する罠に陥らないことは重要だ。それなら、プロジェクトを評価して複雑さのプロファイルを確立する方がはるかに優れている。少なくとも、戦略的な選択肢は意図的なものであって、仮定に基づいてはいないのだ。 複雑さの要素 私は計画段階で、プロジェクトの複雑さのプロファイルを開発するのが好きだ。それは、そのプロジェクトの必要に合わせて、適切なツールや技術を選択するようにプロジェクトチームを導いてくれるからだ。また、特別な注意が必要な中枢要素を識別してくれる。これらの要素を意図的かつ積極的に対処することによって、我々の行動はより戦略的になり、顧客、スポンサー、そして様々な利害関係者にとって価値が増加されることになる。 ここに各プロジェクトにおいて考慮すべき複雑さの要素のいくつかを挙げておく。それらを監視すれば、プロジェクトのライフサイクル全体を通じて、あなたやあなたのチームを導く複雑プロファイルが作成される。 法的環境 市場における競争の激しさ 革新レベル プロジェクトチームの規模 主題の専門家を含め、全体としてのプロジェクトチームが必要とする能力 調達活動 プロジェクトの期間 プロジェクトの一意性 財務分析と要件 利害関係者の数や多様性 結論 我々のプロジェクトの複雑さのレベルを理解することは、戦略的になってプロジェクトのニーズに合わせて最適化された計画を設計するには重要なステップである。プロジェクト管理の方法論は、我々のツールボックスである。他のどんなツールボックス同様に、それを考えないで使用すべきではない。 プロジェクトの複雑さに焦点を当てるのはなぜか。複雑性の高い要素は、多くの場合、特別な注意を必要とするからだ。プロジェクト要件の定義には、これらの制約を考慮に入れる必要がある。 最終的に複雑さのプロファイルは、扱っている状況をより明確に示し、それに応じてカスタマイズされたソリューションを作成することを可能にすることになる。これはフリーサイズ的に迅速で簡単なプロセスではないかもしれないが、プロジェクトの成功には遥かに高い可能性を確約することになる。複雑さのプロファイルが、プロジェクト計画を作成し、プロジェクトに合うツールやプロセスの選択に役立つためだ。

続きを読みます »

会議上の問題をクリアする4つの方法

あなたにとって、驚くべきことかもしれないが、貴社とは違い、建設的でないミーティングがあります。それは確かな事実で、時には結果を生み出さないミーティングがあります。ハリー・ホール氏は会議上の、4つの問題になるであろう問題について書きます。そして、その問題をいかに解決するかを。 はっきりしない目的 課題がコロコロ変わる 中途半端 方向性が明らかでない もし、ミーティングが建設的でないとするなら、そもそも何故に、そのミーティングを開いたかが分からないのが原因です。どのミーティングにも、まず誰かが、簡潔に目的をはっきる述べることで始めるべきです。日程と根本原理を見直してから、追加の課題があるかを尋ねます。 第一の問題に要因する第二の問題は、人間は一つの課題から次々の課題へ順番に、課題に進むことに慣れていない生き物です。人間は、課題と課題を行き来して、話したいので結局、個々の課題について、効率的なトークができないままです。これを乗り越えるためには、ミーティング中に話された重要点のリストをメモって、必要であれば、ディスカッションを向け直す「門番」を指定することもできます。 しかし、いくら計画を立てようと、または構造を変えようとも、ディスカッションについての決断に至らない空気が流れることがあります。誰が決断を下すべきかについては、頻繁に情報不足または不確定であることが挙げられます。同様に、ミーティングへの参加者を8人に限定することで、人数が多く過ぎないので、より早く決断が下ります。 最後に、レイド(RAID)を治療薬として用いることで、方向性が明らかになります。RAIDとは リスク(risk)、 活動アイテム(action items)、 課題(issues) 、そして決断 (decisions)から成ります。 リスク(Risks):リスクの記録に脅威と機会等を確認する事。 活動アイテム(Action items):アクションアイテムは活動アイテムの日付、やるべき行動、責任者、納期、状態 (未完成・完成)。 課題(Issues):ミーティングのイッシュー(課題)は大事な事項でも会議の範囲外にあるアイテムを含めまました。 決断(Decisions):どのデスイジョン(決断)が出ましたか。誰が決めましたか。決断が出た日付は。決断に至る経緯は。 記事の原文はこちらでご覧下さい(英語): http://www.pmsouth.com/2014/11/08/four-meeting-problems-which-ones-do-you-want-to-overcome/

続きを読みます »

リスク所有者についてどの人も知っておくべきこと

回避、管理、およびプロジェクトのリスクを軽減することは、確かにプロジェクト管理者の責任だ。しかし、プロジェクト管理者は一人で多くの任務を負っている。大きなリスクを管理する主要な責任は、他のチームメンバーに委任する必要がある。ハリー・ホール氏は、このような努力の細かい点を説明している。 まず、リスクの所有者を定義する必要がある。リスクの所有者は、必要が生じた場合適切なリスク対応と準備をして、特定のリスクに目を離さない意思を持っている人である。彼らは定量的および定性的な手段を用いて特定のリスクを定義し、分析することを引き受けている。 また、問題のリスクの特定ブランドによく馴染んだ人が必要だ。理想的には、そういう人はリスク管理の経験があり、リスクに応じ得ることで知られている。もちろん、リスク監視を進んで行う必要もある。各リスクを洞窟に潜んでいる超自然的な怪物トロールとして考えることができる。そしてそのトロールが出現する場合、リスク所有者は自らのポストで戦う用意をする必要がある。 潜在的な候補を引き入れるには、プロジェクトの重要性や危険から守られなければならない理由を説明する必要があるかもない。遅くても、リスク所有者をリスク対応計画の書き込み時に選択しておくべきで、唯一の大きなリスクには、リスク所有者と評価計画を持つだけの価値があることを覚えておくべきである – 私たちは小さな怪物ゴブリンについてではなく、大怪物トロールについて話しているのである。 元の投稿(英語)はこちらからどうぞ: http://www.pmsouth.com/2014/09/28/what-everybody-ought-to-know-about-risk-owners/

続きを読みます »

失敗の認識を回避する方法

プロジェクトチームは誇らしげに提供しても、スポンサーが失望しか表さない時、プロジェクトの期待についての根本的な切断をしなければならない。著者スザンヌ・マドセンが書いているように、知覚は、プロジェクトの成否を決定する重要な要因である。 マドセンによると、プロジェクト管理者(PM)は、さまざまな利害関係者の議題を設定する。PMは、各利害関係者が​​プロジェクトから望んでいるものの中で妥協点を見つけなければならない。各当事者が期待を他人のニーズや能力に対して期待を切り替えることに同意しなければならないので、意見の均衡というこの分散の用語は、「相対的な優先度」としておく。 成功したPMは、すべてのプロジェクトは、終わりを念頭に置いて始める必要があることを知っている。期待の設定が成功か失敗かは、共通の目標、利点、締め切り、およびその他の資格をもとにして、関係者の目にどのように測定されるかによって決定される。事前に関係者から要求を求めるようにしておこう。マドセンはさらに詳しく説明している。 最終的にあなたのプロジェクトの成功はあなたのスポンサーや利害関係者が、期待していた方法で、思いどおりの利点を得られたか感じるかどうかによって測定されることを、覚えておこう。そこで、明らかに客観的に述べた基準を定義する必要があるだけでなく、失敗の認識を回避するために、定量化し、測定可能な条件に任意の主観的な感情や文をオンにしておく必要がある。そうしてやっと本当に自分に期待されているものが分かるだろう。 プロジェクトのライフサイクル全体を通じて、述べた目標と利用可能な手段との間の相互作用を考慮することは重要である。これは、必要なリソースが不足している可能性があり、それについて運営委員会に話をする必要があることを意味する。善行も注目に値することを覚えておこう!偉大なプロジェクトを実行するには、たまには小さな勝利を祝うことも含まれるのである。 元の投稿(英語)はこちらからどうぞ: http://www.pmhut.com/how-to-avoid-the-perception-of-failure

続きを読みます »